JP2010511929A - 飲料の開発及び製造を管理するシステム及び方法 - Google Patents

Abstract

飲料の開発及び製造プロセスを管理するシステム及び方法を開示する。この方法は、製品ヒストリを生成するために、飲料の開発及び製造ヒストリを取り込み、記録することを含む。製品ヒストリは、コンピュータに格納され、情報を簡単に取り出すために複数データ次元で検索可能である。このシステムは、飲料産業の規制標準規格を遵守するためにコンプライアンス管理手順を自動的に提供する。
【選択図】図1

Description

(関連出願の相互参照)
本願は、それぞれが引用によって本明細書に組み込まれている、2001年1月23日に出願した米国仮出願第60/263177号の利益を主張する2002年1月23日に出願した米国特許出願第10/052412号の継続出願である2004年8月9日に出願した米国特許出願第10/914538号の一部継続出願である2006年11月30日に出願した米国特許出願第11/663048号の優先権を主張するものである。

(発明の背景)
(発明の分野)
本発明は、規制された産業の管理に関する。具体的には、本発明は、規制された産業の規制、税コンプライアンス、在庫及びe-ウェアハウス管理を容易にする。

(関連技術の説明)
石油及びガソリン、食品(たとえば、農産物、加工食品、獣肉/鶏肉など)、飲料(たとえば、スピリッツ、ビール、ジュースなどの消費できる液体)、化学製品、消費者製品(たとえば、化粧品及びスキンケアなど)、及び調合薬{たとえば、化学開発(製剤原料とも称する)、医薬開発(製剤とも称する)、生物薬剤(製剤原料及び製剤)、並びに後発品}などの厳しく規制されたプロセス指向の産業は、複数の共通の特性を共有する。これらの種類のプロセス産業は、安全で効能のある製品が公衆によって消費されることと、これらの前述の産業の会社によって提示される製品のそれぞれが詐欺的でも有害でもない(たとえば、製品の完全性が製品の寿命の間に維持される)こととを保証するために、米国食品医薬品局(FDA)並びにTrade and Tax Bureau (TTB part of Treasury)など、地方、州、連邦、及び国際機関によって厳しく規制される。製品の完全性は、部分的に、ある時点での製品レコードをこれらの製品の開発、製造、及び市販中の別の時点の製品ヒストリレコードと比較することによって証明される。これは、この種の厳しく規制されたプロセス産業にとって挑戦的である。というのは、本質的に、これらの産業は、動的に変化するか非常に複雑である製品を作る傾向があるからである。したがって、これらの製品ヒストリレコードに関連する情報は、管理がよりむずかしくなる。たとえば、これらの産業は、哺乳類の細胞から分泌されるタンパク又は農産ブドウから分泌されるグレープジュースなど、非常にさまざまな原材料を必要とする場合がある。

「厳しく規制された産業」のもう1つの主要な要件は、会社が、開発から商業的製造までのその生産プロセスが完全にトレース可能であることを実証する能力であり、これは、第三者(たとえばFDAなどの機関)が、来、ある時点から別の時点への製品ヒストリを見ることを要求できることを意味する。たとえば、会社は、「それが製造しているものが、実際に、その会社がそれによって製造していると主張する形で製造されている」ことを証明できなければならない。これらのオンサイト点検、監査、及び情報要求は、しばしば、ある時点から別の時点への材料の特定のセットに関する特定のプロセスに焦点を合わせたものである。製品ヒストリトレーサビリティの不変の証明を提供できない会社は、高い科料並びに操業休止に処せられてきた。

さらに、経時的なプロセスの証明を提供できないことに関して、これらの産業は、通常、提示案出願、監査、商標、廃棄物、排出物、安全性などのすべての部分の非コンプライアンスについて、高い科料又は生産の遅れ/操業停止に処せされる。適当な税の支払いは、継続している課題である。というのは、支払いが、「製造量」及び製造された製品の「タイプ」によって決定され、そのすべてが、経時的な多数の次元に沿った広範囲の記録保持を必要とするからである。

これらの産業は、「非常にプロセス指向」でもあり、これは、製品が、複雑なブレンド、処方、及びレシピなど、ステップの広範囲の組合せからなる形で製造されることを意味する。もう1つの短所は、これらの産業の一部(たとえば、医薬産業及び飲料産業)で、広範囲の記録保持が、製品ヒストリ「文書足跡」を作成するために必要であることである。通常、これらの産業が必要とする種類の記録保持は、しばしば、原材料から最終製品にわたり、サプライチェーンにわたるすべての中間製品を含む、製品のライフサイクルの完全なヒストリである。製品ヒストリの記録保持に必要な情報のタイプは、通常、次の次元すなわち指定されたレコードの包括的情報を集合的に形成する、(a)人員及びそれらの人員のトレーニング要件、(b)プロセス、(c)材料、(d)機器、(e)標準規格、及び(f)施設/環境情報にまたがる。

これらの産業は、作業人員、機器材料、プロセス(たとえば、キャンペーン計画及び実行、作業注文生成など)に関する複雑な注文追跡をも有する場合がある。たとえば、原材料から中間物、最終製品などへの材料の状態の追跡、又は機器ヒストリ(較正、清掃、使用など)の追跡は、複数の異なる種類/部分の情報を必要とし、その追跡が複雑なプロセスになる。これらの分野の情報は、記録され追跡されなければならないだけではなく、会社内で内部的にと、規制する機関によって外部的にとの両方で、制定された標準規格と比較されなければならない。さらに、これらの情報は、異なる時点のその情報自体と比較されなければならない(たとえば、商業的製造が、第9年に行われ、機器セットアップ、較正、清掃、及び使用が記録され、追跡され、第8年の機器ヒストリと比較される。この第8年の機器ヒストリは、規制する機関に提出されたものであり、その会社の商業的製造の認可は、この機器ヒストリに基づく)。

これらのタイプの規制されたプロセス産業は、さらに、複数の異なる間接財/投入財が最終製品を作成する経路に沿って製造され、これらの間接財/投入財/中間財のすべてが、上で説明したように類似する形の情報の記録/追跡/異なる時点との比較で管理されなければならないという点で、さらに能力を試される。可視性は、これらの規制されたプロセス産業でのこの包括的記録保持及び情報の管理を達成するのに必須であるが、現在は、まだ、これらの産業は、プロセス入力とサプライチェーンにわたる製品ヒストリとのすべてのレベルにおいて低い可視性を有する。

一例として、ワイン産業でのコンプライアンスは、ブドウがワイン醸造所に達するや否や、開始される。これは、ワイン醸造所が、どこでブドウが育ったか、ブドウがそのワイン醸造所にどのように出荷されたか、並びに生産、ボトリング、及び熟成の全体を通じて使用された総トン数を追跡しなければならない。製造プロセスは、何年にもわたって進行する可能性がある。さらに、発酵プロセス及びボトリング/熟成プロセス中のアルコール含有量を追跡しなければならない。多数の規制を遵守するワイン醸造所の能力は、在庫にも結び付けられた継続生産プロセス全体を通じて特定の情報を取り込むことを要とするので、コンプライアンスをワイン醸造所のサプライチェーンマネジメントに結び付けることが重要である。

ワイン醸造所はまた、現在、その内部運営への限られた可視性を有し、そのワイン仕掛かり在庫レベルのリアルタイム情報をほとんど有しない。業界のワイン製造側は、しばしば、あるタイプのワインのボトルがそのケラーに何本あるかを報告する能力を欠く。ワイン製造側は、生産レベルを在庫の必要と一致させることがむずかしく、非効率的な購入をもたらすことにも気付く。

ワイン醸造所は、しばしば、さまざまな価格設定合意をもたらす彼らの子会社の間での口頭の又は統合された購入によって形成される好ましいサプライヤリレーションシップを享受する。したがって、ワイン醸造所は、彼らの成分、サプライヤリスト、及びレシピを、高いレベルのセキュリティを必要とする専有情報とみなす。また、ワイン醸造所は、限られたテクノロジスタッフを有し、したがって、より高い外部実務サポートを必要とする。

ワイン産業の一特定の必要に焦点を合わせた既知のコンピュータに基づく製品は、上で説明した問題に対処しない。既知のシステムは、トータルサプライチェーンマネジメントソリューションを欠き、完全な規制及び税のコンプライアンス管理を提供しない。さらに、現在のシステムは、パーシートでのライセンシングを提供するが、内部運営への可視性を提供する限られた能力を有し、特に、会社の全従業員に対するリアルタイムのアクセシビリティを欠く。

ワイン産業での上記の問題の結果として、在庫管理、規制及び税コンプライアンスからのすべて並びに供給側でのその他の履行は、企業の内側と外側と両方で断片化され、労働集中的、非効率的、かつ高コストである。規制及び税のコンプライアンスは、手作業であり、複雑であり、時間がかかる。サプライヤ及びバイヤは、可視性を欠き、親会社は、彼らの子会社の購入カテゴリ及び出費カテゴリに関するリアルタイム情報をほとんど有しない。また、サプライヤの生産とバイヤの需要との間の調整がほとんどない。そのような問題の結果として、ワイン業界で販売される商品のコストは、平均して純収益の50〜80%であり、一般コスト及び管理コストは、しばしば、純収益の10〜35%もの高さである。

現在、厳しく規制された産業のプロセス管理における包括的製品ヒストリ記録保持など、これらの種類の複雑な必要を完全に満足する広範囲のソリューションはない。実際に、連邦及び州の規制に関する記録保持機能及びファイリングプロセスの多くが、まだ、時代遅れの手作業の時間のかかる手段を介して行われている。

(発明の要旨)
本願は、全般的には、その内容が引用によって本明細書に組み込まれている、2004年12月23日に出願した本件出願人の同時係属の米国特許出願第11/022316号、名称「医療の開発及び生産を管理するシステム及び方法(System and Method for Managing the Development and Manufacturing of a Pharmaceutical Drug)」に関する。

本発明は、規制されたプロセス産業の原材料から最終製品までのサプライチェーンにわたる情報管理を可能にするシステム及び方法を説明する。このシステム及び方法は、キーコンポーネントがしばしば動的に変化しており、その管理が非常に複雑である、厳しく規制された製品の広範囲の記録保持を会社が管理することを可能にする。実施態様は、自動化されたコンプライアンス及び税報告を伴う規制及び税データベースを容易にする。たとえば、規制管理及び自動化されたコンプライアンスは、連邦規制機関提出要件へのコンプライアンスと、飲料開発の任意の次元のトレーサビリティと、監査、点検、及び製品完全性審問を満足するのに必要なキー情報の取出とを会社が自動的に実証することを可能にするシステムによって達成される。このシステム及び方法は、コンピュータを用いた在庫及びe-ウェアハウス管理ソリューションと一体化されているので、「商業生産に対する候補選択」からの必須の製品ヒストリ情報が、会社が連邦機関に対してコンプライアンスを実証することを可能にする比較、相関、及び検証のために自動的に取り込まれる。たとえば、原材料、消耗品、及び中間物のフルライフサイクル管理を実証することができる。各ステージの原材料及び中間物に関連するこの情報は、ライフサイクルのフル製品ヒストリを実証するために、会社の記録保持の必要に活用される。実施態様は、たとえば飲料などの規制された産業に適用可能である。

本発明は、完全なリアルタイムのウェブに基づくサプライチェーンインフラストラクチャとの規制コンプライアンス統合が、原材料ステージから最終製品までのすべての必須製品ヒストリを管理することを可能にする。このシステムは、領域仕様、規制仕様、及び税仕様に対処することを可能にする、産業ごとの十分なカスタマイゼーションを有する。完全な製品ヒストリは、(a)人、(b)プロセス、(c)材料、(d)機器、(e)環境/施設、及び(f)標準規格(規制及び内部)という製品開発及び製造の必須次元に沿ったキー情報を含む。本発明は、医薬の開発及び生産の自動化されたコンプライアンス、税報告、及び仕掛かり在庫管理と共に規制(標準規格)の管理を可能にする。

本発明は、コンプライアンスにおいて支援するための一体化された産業固有サプライチェーンアプリケーションを含む、規制及び税コンプライアンス問題に対する産業固有ソリューションを提供する。本発明は、相補的アプリケーションを提供するために、企業資源計画(ERP)、生産実行システム(MES)、実験室情報管理システム(LIMS)、排出及び分散モデリングシステム(emissions and dispersion modeling system、EDMS)、並びに他のシステムなどの既存情報システムと一緒に動作するように設計される。

このシステムは、ユーザが、規制書類提出、税コンプライアンス、及び在庫(たとえば、原材料、中間物、最終製品)を管理することを可能にする。この態様は、リアルタイムのウェブに基づく企業全体のサプライチェーンインフラストラクチャを用いてサプライチェーン非効率性を減らす。現在の面倒な文書足跡の実質的削減が、このシステムによって達成され、ユーザに、より正確でタイムリーなコンプライアンスを与え、したがって、違反及び実質的な科料/罰金が回避される。

このシステムは、規制された産業の運営全体を通じて可視性を高めるサプライチェーンソリューションを提供することができる。この態様は、リアルタイム情報及び高度な計画へのセキュアアクセスを介してより高い情報管理を可能にする。この態様は、コスト及び在庫レベルを減らし、運転資金の必要を減らしながら、心配のない管理をユーザに提供する。このシステムは、無線対応とすることができ、ユーザが、より効率的かつ効果的にクリティカルデータを管理することを可能にする。

このシステムは、明瞭な包括的製品ヒストリ情報を提供でき、会社が、(a)人、(b)プロセス、(c)材料、(d)機器、(e)標準規格、及び(f)環境/施設という複数の次元に沿って、完全性を示し、ある時点から別の時点への製品トレーサビリティを示すことを可能にする。

極端にスケーラブルなプラットフォームを介して、このシステムは、サプライチェーンインフラストラクチャに基づくリアルタイムのウェブに基づく規制及び税コンプライアンスを可能にすると同時に、規制及び税のコンプライアンスモジュール、在庫管理モジュール、コンテンツ管理モジュール、並びにサプライヤカタログ管理モジュールをも提供する。調達ツール、出荷管理ツール、需要及び予測ツール、並びに規制e-ファイリングが、サプライチェーンソリューションを相補する。

このシステムは、多数のサードパーティエンタープライズリソース、プラニングアプリケーション、及び既存レガシシステムとインターフェースすることができる。いくつかの実施態様で、このシステムは、オープンアプリケーションプログラミングインターフェース(API)システムを使用するjavaベースである。このシステムは、非常に拡張性があり、柔軟であり、堅牢であり、モジュラであり、ポータブルである(たとえば、携帯情報端末対応及び無線対応)ものとすることができる。このシステムは、ウェブブラウザのみを必要とし、デスクトップインストールを必要とせずに実施される、シンクライアントアーキテクチャを使用することができる。このシステムは、ブラウザとサーバとの間のコンテンツの伝送を保護するのにセキュアソケットレイヤ(Secure Sockets Layer)(SSL)をサポートすることができる。さらに、ユーザ識別及びパスワードの保護を埋め込むことができると同時に、ユーザの役割に基づくコントロールを埋め込むことができる。

本発明のシステムは、コアプラットフォーム及びモジュールを介して、経時的に複数の次元にまたがる記録保持の広範囲の管理を提供することができる。たとえば、飲料加工の材料管理機能は、本発明のシステム及び方法によって提供される。具体的に言うと、飲料プロセスのための保管のチェーンを記録することができる。いくつかの実施態様で、このシステムは、材料の各タイプのすべての関連する情報(たとえば、仕様など)を管理する。ローディングドックから最終製品までの材料トレーサビリティは、すべての材料について誰が何をどこでいつどのようにしたかを確かに知ることによって提供される。さらに、このシステムを用いて材料を突き止め、作成することが可能である。すべての材料の要求、注文、在庫、分配、処分、及び転送が、既知である。文書化のチェーンは、状況、サインオフ、警告、認証、e-シグネチャ、及びハザードプロファイルの使用を介しても記録される。類似する機能性が、経時的な飲料加工のすべての次元についても存在する。

製品の品質は、このシステムによって管理することができる。材料資格付与IDが、原材料仕様と同様に記録される。材料は、ソートされ、システムによって材料の任意の特性に基づいて追跡され得る。

このシステムは、製造プロセスで使用される機器を管理することもできる。機器使用の予約並びに機器特性、使用、及び可用性は、このシステムを用いて見ることができる。さらに、機器使用、貸出、借用、非作動状態化を追跡することができる。機器の保守及び清掃を、このシステムによって追跡することもできる。

当業者は、下にリストされた図面を参照する好ましい実施態様の次の詳細な説明を読むときに、本発明のさまざまな実施態様の上記及び他の特長及び利益を理解するであろう。

第1実施態様によるシステムを示すブロック図である。 供給側チェーンマネジメントアプリケーションの実施態様の動作を示す図である。 ウェブに基づく供給側チェーンマネジメントアプリケーションを実施するハードウェアコンポーネントを示すブロック図である。 収集され分析されるデータの次元を示す図である。 システムのコアモジュールのプラットフォーム概要を示す図である。

(好ましい実施態様の詳細な説明)
図1は、在庫管理モジュール100、規制モジュール200、コンテンツ管理モジュール300、カタログ管理モジュール400、プロセスモジュール500、サプライヤモジュール600、及びコアモジュール1000を有する製品コンフォーマンス管理システム5のブロック図である。当業者は、使用可能なモジュールの個数及びタイプを、産業タイプに基づいて変更できることを認めるであろう。たとえば、ワイン製造業界について、ブレンド管理モジュール、樽管理モジュール、タンク管理モジュール、ケラー管理モジュール、トライアルブレンディングモジュール、及びワイン調合法モジュールもある場合がある。これに関して、特定の産業のソリューションは、モジュールの集合である多数のスイートを含む場合がある。モジュールのそれぞれが、プラットフォーム上で独立に展開可能である。複数のモジュールを有することによって、ソリューションを、段階的に顧客サイトで簡単に展開し、拡張することができる。下の説明は、ワイン産業に合わせて調整されたものであるが、本発明のシステムを、すべての厳しく規制された飲料プロセス(たとえば、スピリッツ、ビールなどの生産)と共に使用できることを認められたい。

在庫管理モジュール100は、ワイン産業の必要に特に対処するために、ワイン産業の領域知識を含む。具体的に言うと、在庫管理モジュール100は、ラベリングされないブドウ及びジュースの移動及び生産プロセスを介して移動する時のその異なる価値を記録すると同時に、その収穫及び損傷要因を追跡する。さらに、在庫管理モジュール100は、子会社レベル又は会社レベルでの会社の在庫への可視性を提供すると同時に、ワイン醸造プロセスを通じた在庫を追跡する。在庫管理モジュール100は、在庫しきい値レベル及び再注文ポイントを実装し、電子メール、ポケットベル、又はWAPを介する通知をトリガする。在庫管理モジュール100は、ワイン醸造所とそのサプライヤとの両方が、内部在庫レベルを見る能力をも提供する。在庫管理モジュール100は、商品の受取り及び供給、商品の移動、並びに商品位置の検証を提供する。したがって、在庫管理モジュール100は、開発プロセスから生産サイクルへ及びその終りまで商品を追跡することができる。

規制モジュール200は、アルコール製品に関する複雑で変化する政府及び州の規制へのコンプライアンスの必要に対処する。規制モジュール200は、ワイン産業に影響する現在の規制及び税のコンプライアンスの情報を提供する。この規制及び税データベースは、自動化されたコンプライアンス及び税の報告をも含む。規制モジュール200を、米国食品医薬品局(FDA)、アルコール、たばこ、火器局(BATF)、州機関、及びこのデータベースを作成するための法的情報の他のオンラインソースにリンクすることができる。プラットフォーム(コアモジュール1000)と組み合わされた規制モジュール200は、電子製品ヒストリレコード(ePHR)を開発と製造との両方について作成することを可能にする。

コンテンツ管理モジュール300は、業界ニュース、文書、在庫警告、気象パターン、農業データ、在庫警告、仕様書、分析証明書、方法、及び標準規格などの業界固有情報、会社固有情報、アクティビティ固有情報、又はサプライヤ固有情報の関係データベースである。

製品を売るサプライヤは、通常、オンライン又はハードコピーのいずれであれ、ある種のカタログを有する。カタログ管理モジュール400は、製造業者(たとえば、ワイン醸造所)に複数のサプライヤにまたがる類似する製品の合併されたビューを与え、成分のリスト、各製品に関連するコスト、各製品の調達関連情報、及びリリース情報を会社に与える。

プロセスモジュール500は、飲料生産プロセスのさまざまなステージからのデータを取り込む。取り込まれるデータに、アクティビティレコード又は研究所分析レコードを含めることができる。これらのレコードは、材料のすべてのステージ(原材料から中間物、バルク製品(bulk product)、最終製品まで)の監査及び規制コンプライアンスのトレーサビリティを可能にする。プロセスモジュール500は、キャンペーン計画及び実行を介する広範囲の記録保持をも可能にし、すべてのプロセスステップ、かかわる人、使用される機器、使用される材料、従われる標準規格、及び施設位置情報を結び付ける。

サプライヤモジュール600は、会社によって購入された製品のサプライヤ及び関連するカタログ並びにその取引に関連するコストを管理する能力を会社/ユーザに提供する。サプライヤモジュール600は、コアモジュール1000と共に、会社が、その会社によって購入される製品に関する情報を追跡し、記録する自動化されたシステムを有することを可能にする。

コアモジュール1000は、「製品コンフォーマンス管理(PCM)プラットフォーム」とも称するが、システム5の基礎モジュールである。コアモジュール1000は、システム5の機能性を実施し、会社内のさまざまなビジネスプロセス及び規制プロセスのために顧客が構成できる共通プラットフォームである。コアモジュール1000は、ある顧客の規制されたプロセスに関する材料、機器、プロセス、人、標準規格、及び環境に関するすべての情報のライブラリを管理する。コアモジュール1000は、顧客の要件に従ってすべての属性を動的に定義する。コアモジュール1000は、範囲又は列挙のいずれであれ、有効な値を提供し、データ型及び値生成アルゴリズム(存在する場合に)を定義する。コアモジュール1000は、測定の単位をも定義し、異なる単位の間の変化をサポートすることができる。

さらに、コアモジュール1000は、すべての情報オブジェクトの状態、承認のためのワークフロー、及び「状態」変化を管理する(たとえば、動的で非常に可変の変化の管理)。サイト及び位置並びに組織階層が、コアモジュール1000によって管理される。コアモジュール1000は、ユーザ、ユーザグループ、及びユーザ機能を管理し、アラートをセットアップすることとアラートにサブスクライブしたユーザに通知を配送することとのためのインフラストラクチャを提供する。コアモジュール1000は、検証されたモードでソフトウェアシステムの間でデータを移動し、政府規制(たとえば、連邦規則第21条第11章)へのコンプライアンスを保証する。さらに、バージョニングサポートが、コアモジュール1000内で提供される。コアモジュール1000は、システム内で取り込まれるデータに対する変更の監査証跡、システム内のすべての情報オブジェクトへの添付ファイル、及びシステム内のすべての情報オブジェクトに添付される任意の個数の注記を作成することもできる。

システム5のセキュリティを維持するために、コアモジュール1000は、ユーザ識別及びパスワードの組合せであるログインを介するアクセスを提供する。いくつかの実施態様で、3回の不成功のアクセスの後に、ユーザアカウントがディスエーブルされ、管理者に通知される。いくつかの実施態様で、管理者だけが、アカウントをアンロックする能力を有する。さらに、ユーザ名、肩書、電子メールアドレス、電話番号、システムの使用の有効日付、及びユーザの物理的位置に関する詳細が、コアモジュール1000によって維持される。ログインサービスは、ユーザがアクセスするために許可されるシステム5のアプリケーションのすべて及びアクセスが許可される役割をも識別する。

いくつかの実施態様で、コアモジュール1000は、これによってユーザを外部システムによって認証できる外部認証サポートを提供する。外部サービスは、ユーザの識別及びパスワードを用いて呼び出される。コアモジュール1000は、システム5内の認証プロセスに似た成功の試み及び不成功の試みを処理することができる。外部認証が使用されるときに、すべてのアカウント及びパスワード管理は、外部サービスによって処理されなければならない。

システム5は、アクセスについてさまざまな役割をモデル化することができる。これらの役割は、企業内の個人の機能的役割にマッピングされる必要がないはずである。システム内で定義される役割は、主に、システムのさまざまな特徴へのアクセスを制御するのに使用される。役割は、1つのアプリケーションに関連付けることもでき、或いは、アプリケーションのすべて若しくは組合せにとって使用可能とすることもできる。役割は、位置固有又は企業全体とすることができる。ユーザは、システム内で複数の役割を有する能力を有する。役割は、その役割がアクセスできるシステムの機能性(たとえば、メニュー項目、スクリーンなど)を識別する。さらに、役割は、その役割が、それがアクセスできる機能性に対して実行できるアクション(たとえば、読取り、書込み、更新、削除、リストなど)を識別する。役割は、アクセス可能な特定のフィールド/属性を識別する。

システム5へのレコードの入力を認証するために、コアモジュール1000は、ユーザシグネチャを電子的に収集する包括的方法の使用をサポートする。このサービスは、電子署名の必要が生じるときに、いつでもアプリケーションによって呼び出すことができる。ユーザは、正確さのために検証されるユーザのID及びパスワードを促される。再利用可能なユーザインターフェースコンポーネントが、電子署名の簡単で一貫した実施態様を保証するためにすべてのアプリケーションについて使用可能である。この再利用可能なコンポーネントは、パラメータとしてユーザのIDを受け入れ、ユーザインターフェースがユーザに提示されるときにその情報を事前に充てんする。これは、シグネチャの連続するセットが受け入れられることを必要とするときに助けになる。各シグネチャは、ユーザによって証明/署名されるアクティビティに対して格納される。

アラートは、システム5にとって非常に重要である。アラートは、多数のアクティビティ及び先を見越した通知に使用される。したがって、アラートは、非常に拡張性があり、包括的である。顧客は、アラートを、システムをシャットダウンせずにいつでもアプリケーションによって識別されるオブジェクトに関連付けることができる。

各アプリケーションは、それに関連するアラート(たとえば、作業注文、材料受取り、機器スケジュールなど)を有すると期待されるオブジェクト及びその値の変化がアラートをもたらすオブジェクトのさまざまな属性を識別する。アラートを生成するために属性に対して実行される比較のタイプを定義することが可能である。すべての一般的なタイプの比較すなわち、範囲又はリストと等しい、等しくない、より大きい、より小さいをサポートすることができる。

アラートをトリガするアクションのタイプは、オブジェクトを変更する(作成、変更、削除)ユーザアクション及び時間に基づくトリガ(期限を過ぎたアクティビティのチェック)である。オプションとして、アラート条件に達したときに実行されるカスタムコードを付加することが可能である。これは、通知を生成するのに必要な場合に、計算論理を埋め込むのを助ける。

展開されたシステムで、管理者は、システム5のユーザに使用可能なアラートを公開することができる。これは、所与のアラートにサブスクライブすることを可能にされる役割及び/又はユーザを識別することによって行われる。パブリケーションは、包括的なシステム全体のパブリッシュ/サブスクライブ機構を介して達成される。

あるユーザが、アラートに対し承諾することを試みるときに、そのユーザに公開されるアラート及びそのユーザの役割だけが、いくつかの実施態様でリストされる。次に、ユーザは、承諾したい実際のアラートを選択し、サブスクリプションを完了するのに必要な情報を提供することができる。ユーザインターフェースを介して、エンドユーザは、通知される時の正確な条件を定義することができる。エンドユーザは、オブジェクト及びその属性を選択し、通知をトリガする値を割り当てる能力を有する。ユーザのオブジェクトレベルパミッションに応じて、ユーザは、そのユーザが読取りアクセスを有する属性についてのみ通知判断基準を指定することができる。

ユーザは、通知の配送の方法を選択する能力を有する。通知は、システム5内でユーザのパーソナルアラートリストに配送される。さらに、ユーザは、アラートを電子メールによって配送させることを選択することができる。アラート通知を、その代わりに又はそれに加えて、ポケットベル及びセル電話機に配送できることをも認められたい。

ユーザが正しく警告されることを保証することは、システム5の、したがってコアモジュール1000の主要な責任である。システム5のページのそれぞれのアラートペインは、コアモジュール1000によって生成される。このペインは、アラート及び通知のある主要な属性を識別する。ユーザが、システム5の任意のアプリケーション内でアクティブであるときに、アラートペインは、そのユーザによって肯定応答されていない最新の通知を用いて常に更新される。

ユーザへのすべての通知は、アラート通知専用のインターフェースを介して見ることができる。ユーザは、このインターフェースを介して通知の関連する詳細のすべてを見ることができ、通知を管理することもできる。ユーザは、通知がアラートペインにもはや表示されないようにし、かつ/又は通知を削除するために、通知を見たことを肯定応答することができる。

システム5のアプリケーションは、複数の市販のエンタープライズアプリケーション及びニッチ製品並びに多数のカスタムインハウスソリューションと共存する必要がある。アプリケーションを成功して展開し、電子製品開発のリポジトリを提供するために、コアモジュール1000は、他のシステムと簡単にデータを交換できなければならない。これを達成するために、コアモジュール1000は、統合を構成するか作成するのに使用される統合フレームワークを提供する。このフレームワークは、次の要件に従う。

ミドルウェア独立。ベンダ固有ミドルウェア製品に基づく仮定は行われない。展開エンジニアは、顧客によって指定され得る任意の外部システム又はミドルウェア(たとえば、TIBCO、WebMethods、SeeBeyond、Vitriaなど)と通信するようにフレームワークを構成することができる。ウェブサービス及びJSMなどの業界標準が、好ましい実施態様でサポートされる。

XMLデータフォーマット。いくつかの実施態様で、システムの間で移動するデータは、業界の傾向に従うためにXMLで符号化される。いくつかの実施態様で、World Batch ForumのBatchMLなどの既存の業界標準仕様がサポートされる。

統合イベントに基づくトリガ。このフレームワークは、データ変更トリガに基づいて並びに周期的バッチモード更新を介して、リアルタイムでデータを移動することができる。統合フレームワークは、これを達成するために、包括的なシステム全体のアラート通知フレームワークにフックすることができる。

バックエンド(アプリケーションレベル)統合サポート。イベントトリガに基づいて、このフレームワークは、ウェブサービス、URL(httpポート)、JMSサーバに、又はシーケンシャルにラベル付けされたファイルへの単純なエクスポートを介して、データをポストすることができる。統合フレームワークは、ウェブサービス又はJSMサーバを介して着信データを受け入れることができる。

両方向データ交換。システム5は、システムからデータをパブリッシュすると同時に、システム内でデータを挿入し、変更する能力を提供することができる。

レコードのシステムの識別。システム5は、アプリケーションのリストを定義し、システムのうちの1つを各データアイテムのレコードの所有者(マスタ)として定義する能力を有する。

組織的マッピング。一般に、組織単位の名前は、交換されるデータのコンテキストを提供するために必要である。特定の組織単位に与えられる名前は、異なる外部システムの間及びシステム5の外部システムの間で異なる可能性がある。コアモジュール1000は、これらの名前をマッピングする手段を提供する。このマッピングを、単純な1←→1マッピングであると仮定してはならない。

属性マッピング。1つのデータアイテムが、2つの異なるシステムで2つの異なる名前によって識別される場合がある。このフレームワークは、包括的名前マッピング機能性(たとえば、統合がミドルウェアなしで展開される場合)を提供しなければならない。マッピングは、開発中と開発後との両方でオンサイトで構成可能でなければならない。マッピングの複数のグループを、マッピングセット識別子を使用して特定の外部システムに関連付けることが可能でなければならない。

UOMマッピング。パラメトリックデータについて、特定のデータアイテムについてソースシステムで使用される測定の単位が、ターゲットシステムが期待している測定の単位と異なることが一般的である。いくつかの実施態様で、統合フレームワークは、これを処理する機構を含む。いくつかの実施態様で、マッピングは、展開中と展開後との両方でオンサイトで構成可能である。いくつかの実施態様で、マッピングの複数のグループを、マッピングセット識別子を使用して特定の外部システムに関連付けることが可能である。

後方互換性。好ましい実施態様では、このフレームワークは、パブリッシュされたオープンなアプリケーションプログラミングインターフェース(API)を定義する。いくつかの実施態様で、APIに対する些細なリビジョンバージョン変更は、そのAPIを使用して作成された統合に対する変更を必要としない。バージョン非互換性がある場合には、バージョン不一致が検出され、報告されなければならない。

性能及びスケーラビリティ。トランザクションは、システム5によって処理されるトランザクションの個数に正比例して処理される。理論的に、システム内の任意のオブジェクトの編集は、統合フレームワークを介するデータ移動をトリガすることができる。統合フレームワークによってトランザクションに課せられるエンドツーエンド遅延及びスループットオーバーヘッドは、実際のユーザによって経験される全体的なエンドツーエンド遅延又はスループットにおける主要な要因ではない。

ロギング。データ交換イベントは、フレームワークによるデバッグのためにエラーと共にログ記録される。オプションで、デバッグログが、データ移動を追跡するのを助けるために使用可能である。すべてのログは、ユーザ指定の位置にあり、自己維持式でなければならない。ログが、プリセットされたサイズに達するときに、そのログは、クローズされ、アーカイブとして名前を変更されなければならず、ロギングは、新しいファイルに継続される。

管理サポート。フレームワークは、管理者がすべてのアクティブな構成された統合(たとえば、それについてメッセージがパブリッシュされているか受信されているオブジェクト)を識別し、そのヘルスを監視するためのユーザインターフェースを提供する。管理者は、このインターフェースから、新しい統合を構成し、特定の統合をイネーブルし、ディスエーブルし、(デバッグ、イベント、エラー)ログを点検することができる。

システム構成可能性。交換すべきデータ、データマッピング、及び交換の方向は、顧客の必要に基づいて展開の時に構成可能である。構成を、構成ファイル内のある種のエントリ及びいくつかのグラフィカルユーザインターフェース駆動データエントリに制限することができる。

システム5の目標は、情報共有を可能にすることである。データベースに基づくシステムは、これを簡単に達成できるものにするが、異なる情報をユーザ又は外部インターフェースに特に配送しなければならない多数の実例がある。これを達成するために、システム5は、情報をパブリッシュし、サブスクライブするための包括的機構を提供する。この機構は、パブリケーションの候補になり得るアプリケーション内のさまざまなオブジェクトを登録する能力を有する。オブジェクトは、アラート、スコアカード、レポート、データパッケージなどとすることができる。パブリッシュのルールは、パブリッシュされるオブジェクトのタイプに基づく。いくつかの実施態様で、このシステムは、少なくとも次の3つのタイプのパブリケーションをサポートすることができる。
システム定義 - システム内で事前に構成され、除去はできない、
管理者定義 - 管理者のみによって管理される、及び
エンドユーザ定義 - エンドユーザによって管理される。

パブリケーションの時には、パブリケーションにサブスクライブすることを許可されるユーザ、ユーザグループ、及び役割を識別することが可能でなければならない。システム内のすべてのユーザが、自分にパブリッシュされたさまざまなアラートをルックアップすることができ、どのアラートへのサブスクライブを望むかを判断することができる。ユーザが、パブリケーションにサブスクライブしている間に関心のあるオブジェクトを識別するための追加情報を提供することを可能としてもよい。たとえば、あるアラートにサブスクライブしている間に、ユーザは、その下で通知が生成されなければならない条件を提供することができる。

ワークフローは、システム5によって提供される重要でクリティカルなサービスである。すべての会社において、プロセス、役割、及び機能は、常に変化している。状態及びルーティング情報をシステム内の任意のオブジェクトに関連付け、そのオブジェクトがそれ相応にルーティングされることを保証するのにワークフロー機構を使用することが可能である。システム5は、オブジェクトのデフォルトワークフロー並びに動作モード固有ワークフローをサポートすることができる。

アプリケーションプログラマは、ワークフローを通過するはずのアプリケーション内のオブジェクトタイプを登録することができる。アプリケーションは、その内部論理に基づいてワークフローをトリガすることができる。ワークフローサービスは、オブジェクトの現在の状態を判定し、そのオブジェクトを、その状態に基づいてワークフローを介して伝搬させる。状態シーケンスは、システム5のトランザクションレイヤ内で定義され、制御される。

ワークフローは、あるユーザから次のユーザへの順次の又はあるユーザから複数のユーザへの並列のルーティングを可能にする。さらに、ワークフローは、並列ルーティング又はあるユーザ若しくはユーザ役割へのルーティングの後の同期化を可能にする。そのアクションがオブジェクトの状態を変更しないオブジェクトのオプションの受取り側も、ルーティングされる。ワークフローは、応答がユーザ定義の時間制限内にプライマリアプルーバ(approver)から受け取られない場合に、バックアップアプルーバへのルーティングをも可能にする。エンドユーザは、オブジェクトが通過するワークフローを見ることができなければならず、ワークフロー内のオブジェクトの現在位置をも見ることができなければならない。

アプリケーションが、ルーティングのためにオブジェクトをサブミットするときには、必ず、ワークフローマネージャが、現在の状態を判定し、チェーン内の次の1以上のユーザ用のアラートを生成する。ユーザは、オブジェクトをそれに対応する「Locate(突き止め)」ページから又はユーザのホームページ若しくはワークスペース内の保留中のアクティビティのリストから突き止めることによって、アラート通知上のハイパーリンクから直接に実際のオブジェクトにたどり着くことができる。

ユーザがオブジェクトを得たならば、そのユーザは、そのオブジェクトに対して行うことができるアクションのリストを提示される。これらのアクションは、そのオブジェクトについて定義された状態遷移シーケンスによって決定される。

多くの産業が、非常に文書駆動である。非常にしばしば、ユーザが関心を持つ特定の情報が、文書でのみ入手可能である。システム内のどのオブジェクトが添付ファイルを有するかを予測することも、むずかしい。これは、ユーザが作成する許可を有するシステム内の任意のオブジェクトにユーザがそれを介して文書を添付することができる包括的フレームワークを必要とする。ユーザは、サーバ上の制御された共有区域にアップロードされる、ローカルシステム上のファイルを識別できなければならない。プライマリオブジェクトを見ることを許可されるすべてのユーザが、添付ファイルを見ることをも許可されるはずである。いくつかの実施態様で、1つのオブジェクトが有することのできる添付ファイルの個数に対する制限はない。ローカルシステムは、添付ファイルを表示できるビューワを有することができる。

いくつかの実施態様で、アプリケーションプログラマは、ライフサイクルマネジメント用のオブジェクトタイプを登録することができる。この登録は、そのタイプのすべてのオブジェクトが監査証跡にコミットされることを保証する。いくつかの実施態様で、ユーザインターフェースを介してオブジェクトを再構成することが可能である。いくつかの実施態様で、システム内の1つの場所で、監査証跡に集められているすべてのオブジェクトタイプを判定することが可能である。

いくつかの実施態様で、システム5内の各すべてのオブジェクトが、日付及びタイムスタンプを有する。いくつかの実施態様で、タイムスタンプは、ほぼ秒単位で正確である。いくつかの実施態様で、ユーザの物理的位置にかかわりなく、スタンプは、イベントのシーケンスに関する曖昧さを除去するために、システム内のすべてのオブジェクトについて単一のタイムゾーン内にある。

コアモジュール1000のデータモデルレイヤは、システム5のアプリケーションの開発者及びこのシステム内のキーオブジェクトを定義する必要があるエンドユーザに柔軟性を提供する。データモデルレイヤは、展開の後であっても拡張性を必要とするシステムのさまざまな次元を構築するフレームワークを提供する。システム5は、新しいオブジェクトセットを定義し、それらの下で分類階層を構築する能力を提供する。アプリケーションプログラマは、包括的アクセス機能性を使用して、オブジェクトを操作するか、特殊化されたビジネス論理を実施するために自分自身の特定のオブジェクトを定義することができる。再利用可能なユーザインターフェースコンポーネントが、このレイヤで提供される機能性をアプリケーション内で呼び出すために使用可能である。

新しいオブジェクトカテゴリを階層内の任意の場所に追加することが可能である。新しいカテゴリの追加は、ユーザが、階層内のその位置を識別し、これに一意の識別を与えることを必要とする。好ましくは、カテゴリの名前は、その階層内で一意である。

カテゴリが、階層に追加されたならば、カテゴリのプロパティを定義することが可能である。ユーザは、プロパティの名前、データタイプ、及びサイズを提供し、プロパティ内の値が一意である必要があるかどうかを識別し、プロパティのデフォルト値を定義し、有効な列挙値又は値範囲を定義する。通常、カテゴリは、その先祖のプロパティを継承する。

システム内の各次元でオブジェクトに関する情報を有することは、役に立つが、次元の間の関係を作成できることが、通常の実施態様で要件である。システム5は、電子開発レコードのリポジトリを有し、さまざまな次元の間での関係を追跡することが、主要な焦点である。アプリケーションプログラマは、オブジェクトと関係のプロパティとの間の関係を登録することができる。この概念は、追加の関係を展開タスクの一部として作成できることを保証するために拡張することができる。

コアモジュール1000及びその上で作成されるアプリケーションの挙動は、システム上で構成される動作モードに依存する。動作モードは、任意のオブジェクト、あるオブジェクトが通過する状態、及びデータの検証用のルールに関連するワークフローを決定する主要な要因である。コアモジュール1000は、システム5の任意の個数の動作モードを定義する。アプリケーションは、その挙動を決定するために動作モードを使用する。

属性のデフォルト値及び有効な値は、さまざまな次元のデータモデルレイヤ内で定義することができる。しかし、これらの値は、動作モードに基づく変更の対象になる。さらに、トランザクション自体に関するデータの検証は、通常の実施態様で動作モードに依存する。これは、動作モードに依存する検証判断基準を定義するサービスをプラットフォームが提供することを必要とする。そのような判断基準が、このレイヤで提供されない場合には、システムは、通常の実施態様でデータモデルレイヤで提供される判断基準をデフォルトとする。

ワークフローを通過することを必要とするすべてのオブジェクトについて、状態遷移シーケンスを定義することが可能である。状態シーケンスは、動作モード及び/又は位置によって変化する場合があり、状態シーケンスを変更することが可能である。そのような変化が発生するときに、オブジェクトが通過する正確な状態シーケンスを決定することを可能にするために、状態シーケンスをバージョニングしなければならない。

必要なすべてのレポート及び電子開発レコードなどの大きいデータセットに対して行われる必要がある計算を予測することは、むずかしい。コアモジュール1000は、この複雑なデータに達するさまざまな簡単な方法を提供するために、システム5内の「Locate」機能を有する。Excelは、多数の産業で選ばれたツールなので、ユーザは、通常の実施態様で、これらの検索から返されたデータをExcelにエクスポートする能力を有する。

いくつかの実施態様で、システム5内の各アプリケーションは、そのレポートを定義し、それらのレポートを役割に関連付けることができる。これらのレポートは、その役割に割り当てられたすべてのユーザから使用可能である。レポートは、通常、外部レポートライタを使用して定義することができ、対応するレポートジェネレータによって供給することができる。新しいレポートの必要は、ほとんどの会社で定期的に生じる。したがって、いくつかの実施態様で、システムに新しいレポートを継続的に追加し、これらをシステム内で定義された役割に関連付けることが可能である。これは、ユーザによるレポートの選択が、そのユーザがシステムにログインするときに自動的に更新されることを保証する。

いくつかの実施態様で、ユーザは、要求されるレポートの検索判断基準を提供することができる。これは、ユーザが、そのユーザが関心を持つサブセットのみに関するレポートを得ることを保証する。システム5のアプリケーションは、アプリケーションにとって重要なデータパッケージを事前に定義することができる。これらのパッケージは、事前定義のレポートの集合とすることができ、スコアカード、チェックリスト、及びシステム内の検索判断基準を含むことができる。パッケージが定義されたならば、プラットフォームの包括的パブリッシュ/サブスクライブサービスを使用して、そのパッケージをパブリッシュし、それにサブスクライブすることが可能である。

コアモジュール1000は、ダッシュボードを定義する包括的フレームワークを提供する。これらのダッシュボードは、システム内のあるタイプのオブジェクトに基づく集約可視性を提供する。ダッシュボード内のプライマリオブジェクトは、ある位置に固定された機器、ある位置にある現在アクティブなチケット、ある位置にある現在アクティブなプロジェクト、ある位置にある材料ステージング要求、特定のキャンペーンのさまざまなステップなどのオブジェクトである。

ユーザは、ダッシュボードから個々のオブジェクトのいずれの詳細にもドリルダウンすることができなければならない。ダッシュボードは、ユーザが関連する情報をルックアップすることもできるようにするために、他の関連するオブジェクトへのリンクを表示する。いくつかの実施態様で、ユーザビリティ及び情報集約は、ダッシュボードがすべてのアプリケーションに関するアクセスの最も共通の点の1つになるものである。

いくつかの実施態様で、システム5のアプリケーションは、全世界での事業を有する大会社で使用するためのものである。これは、ローカル標準規格に起因してこうむる変動をサポートする要件に自動的に変換される。いくつかの実施態様で、コアモジュール1000及びシステム5のアプリケーションは、国際化され、ユーザ定義可能なデータフォーマット(dd/mm/yyyy、mm/dd/yyyy、及びdd-mon-yyyy)、ユーザ定義可能な時間フォーマット及びタイムゾーン、ユーザ定義可能な1000の区切り記号及び基数点、並びにユーザ定義可能な測定単位をサポートすることができる。このシステムは、非常に構成可能なので、ユーザインターフェースの「知覚される」静的部分の一部になるすべての構成情報が、ローカライズ可能でもある必要がある。

コアモジュール1000並びに関連するアプリケーション及びモジュールによって収集される情報は、データモデルレイヤ内で格納され、ソートされ、このデータモデルレイヤは、ソートされる情報の間の相関を可能にする。具体的に言うと、データは、すべての主要な開発アクティビティを表す複数の次元の間で格納される。図4を参照すると、次元400は、人400a、材料400b、プロセス400c、環境400d、機器400e、及び標準規格400fである。当業者は、次元が、望まれる場合に異なるラベルからなることができることを認めるであろう。各次元は、システム5を用いて記録される情報のタイプ、属性、及び状況を分類する。たとえば、機器次元400e及び材料次元400bは、タイプを分類すると同時に、機器及び材料の属性及び階層を定義する。さらに、機器次元400eと材料次元400bとの両方が、機器及び材料に関するデフォルト限度及び有効な値をセットする。人次元400aは、人の役割及びグループを分類すると同時に、役割階層及び特権アクセスを定義する。人次元400aは、デフォルト限度及び有効な値をもセットする。プロセス次元400cは、プロセスのタイプを分類し、その階層を定義する。さらに、プロセス次元400cは、ワークフロー及びビジネスルールをセットし、ワークフローテンプレートを作成する。環境次元400dは、環境のタイプを分類すると同時に、その属性及び階層を定義する。デフォルト限度及び値並びに環境参照標準規格が、環境次元400dでセットされる。標準規格次元400fは、標準規格のタイプを分類し、構造データ標準規格を作成する。さらに、標準規格次元は、参照文書及び事前定義のプロセスを分類することができる。

相関を、データを介してふるい分けをするために異なる次元の間で行うことができる。たとえば、相関の使用は、関連する情報の検索、比較、検証、レビュー状況などを含む。相関は、情報の「コンテキスト」を判定するために、経時的に及びイベントにわたって使用することができる。たとえば、図4を参照すると、人次元、プロセス次元、環境次元、及び機器次元400が、情報にコンテキストを与えるために相関される。情報を、いつでも所与のイベント(たとえば、条件)について突き止めることができる。コンテキスト、相関、及び次元データ構造は、材料の電子開発レコード(eDR)を簡単に検索することを可能にする。これに関して、電子開発レコードは、アラート及び通知、製造過程運営管理、知識管理、並びに開発ヒストリアーカイバルを提供する。

経時的に、eDRは、会社が、飲料のプロセス、材料、及び構成において、プロセス理解を特定のステップに相関させることを可能にする。

図5を参照すると、コアモジュール1000の一実施態様のプラットフォーム概要501が示されている。プラットフォーム概要501は、一実施態様によるコアモジュール1000のアーキテクチャの4つのレイヤを示す。具体的に言うと、コアモジュール1000の一実施態様は、分析レイヤ500、トランザクションレイヤ502、データモデリングレイヤ504、及び共有サービスレイヤ506を有する。コアモジュール1000は、製品レコードの基礎を作成するためにサービス、機能、及びデータモデルを提供する企業全体のプラットフォームを確立する。いくつかの実施態様で、このアーキテクチャは、オープン標準多層エンタープライズアーキテクチャ用のJ2EEテクノロジを活用する。さらに、このアーキテクチャは、アプリケーションの開発用のパブリッシュされたインターフェースを提供し、オープンインターフェース、ウェブサービス、及びXMLを介する相互運用性を保証する。

分析レイヤ500は、データパッケージ510、ダッシュボード512、スコアカード514、及びレポートモジュール516を含む。分析レイヤ500は、事前定義のレポート及びデータパッケージ並びに事前に構成されたスコアカードを提供する。さらに、分析レイヤ500は、ダッシュボード可視性と役割に基づくレポート及びインジケータとを保証する。

トランザクションレイヤ502は、コンテキスト管理518、動作モード管理520、及びトランザクション管理522を有する。トランザクションレイヤ502は、事前に定義されたビジネスプロセス及びフォームテンプレートを提供し、ベストプラクティスを実施する。さらに、トランザクションレイヤ502は、単一のユーザインターフェース、生産全体を通じたロットトレーサビリティ、及び進行中の可視性を提供する。

データモデルレイヤ504は、相関モデリング524及び次元モデリング400を含む。この実施態様では、データモデルレイヤ504は、1回構成されることだけを必要とし、マスタライブラリを含む。データモデルレイヤ504は、スケーラブルであり拡張可能であり、関連する内容の中央リポジトリを提供する。これに関して、データモデルレイヤ504は、すばやく展開され、再利用を促進する。

共有サービスレイヤ506は、セキュリティ、データ管理、パブリッシュ及びサブスクライブサービス、検索サービス、並びに統合フレームワークを提供する。

図2は、規制された産業のサプライチェーンソリューションを使用可能にするインフラストラクチャを提供するために本発明と一貫する実施態様の動作を概念的に示す図である。サプライチェーンソリューション10は、ウェブサイト12と共に使用され、ウェブサイト12は、それを介してユーザが在庫、生産などの心配のない管理にかかわることができる1以上のアプリケーションを表す。システム22を有するユーザは、たとえば生産の状況に関する情報を入手するために、インターネット16又は他のタイプのネットワークなどのネットワーク接続を介して通信するウェブブラウザ26を使用して、オンラインで(又は他の形で)ウェブサイト12と対話することができる。

図3は、規制された産業のサプライチェーンソリューションを可能にするシステムを実施するための例示的ハードウェアコンポーネントを示すブロック図である。システム30は、IP注文に参加するためにネットワーク接続を提供する、インターネットなどのネットワーク60に接続されたユーザマシン38を有するユーザシステム37を含む。ユーザシステム56などの他のユーザシステムをも、生産状況を入手するためにネットワーク60に接続することができる。ユーザシステム56及び他のユーザシステムは、ユーザシステム37と同一のコンポーネントを含むことができる。

ユーザシステム37及び56のユーザは、生産状況情報を入手するためにサーバ76と対話する。サーバ76は、それを介してユーザが情報を入手でき共有できるアプリケーション(1以上)へのネットワーク接続を提供するためにウェブサイト12を提供し、維持する。システム30は、望まれる場合にインターネットからコンテンツを入手するために、1以上のウェブサイトサーバ58にアクセスする能力をも含むことができる。例示のために2つのユーザシステムだけが図示されているが、システム30は、多数のユーザマシンを含むことができ、ネットワークにユーザマシンを追加し又はネットワークからユーザマシンを削除するためにスケーラブルとすることができる。

例示的なユーザマシン38は、メモリ40、セカンダリストレージデバイス50、プロセッサ52、入力デバイス54、ディスプレイデバイス48、及び出力デバイス46を含む。メモリ40は、ランダムアクセスメモリ(RAM)又は類似するタイプのメモリを含むことができ、プロセッサ52による実行のために1以上のアプリケーション44及びウェブブラウザ42を格納することができる。セカンダリストレージデバイス50は、ハードディスクドライブ、フロッピディスクドライブ、CD-ROMドライブ、又は他のタイプの不揮発性データストレージを含むことができる。プロセッサ52は、メモリ40若しくはセカンダリストレージ50に格納された又はインターネット若しくは他のネットワーク60から受信されたアプリケーション若しくはプログラムを実行することができる。

入力デバイス54は、キーボード、マウス、カーソル制御デバイス、タッチスクリーン、マイクロホン、ディジタルカメラ、ビデオレコーダ、又はカムコーダなど、マシン38に情報を入力する任意のデバイスを含むことができる。ディスプレイデバイス48は、たとえばコンピュータモニタ又はフラットスクリーンディスプレイなど、ビジュアル情報を提示する任意のタイプのデバイスを含むことができる。出力デバイス46は、プリンタなど、情報のハードコピーを提示する任意のタイプのデバイスを含むことができ、出力デバイスの他のタイプは、スピーカ又はオーディオの形で情報を提供する任意のデバイスを含む。

ウェブブラウザ42は、ウェブサイト12を介してアプリケーション(1以上)にアクセスし、それを介してユーザが情報を交換できるさまざまなウェブページを表示するのに使用され、これらのウェブページの例は、下で説明する。ウェブブラウザの例は、Netscape Navigatorプログラム及びMicrosoft Internet Explorerプログラムを含む。ネットワークからコンテンツを取り出し、ページ若しくはスクリーンを表示することのできる任意のウェブブラウザ、コブラウザ、又は他のアプリケーションを使用することができる。

ウェブサイト12と対話するユーザマシンの例は、パーソナルコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、パームトップコンピュータ、ネットワークコンピュータ、又は、ウェブブラウザ若しくはシステムと対話する他のタイプのアプリケーションを実行できる任意のプロセッサ制御デバイスを含む。

サーバ76は、通常、メモリ62、セカンダリストレージデバイス74、プロセッサ72、入力デバイス70、ディスプレイデバイス68、及び出力デバイス66を含む。メモリ62は、RAM又は類似するタイプのメモリを含むことができ、プロセッサ72による実行のために1以上のアプリケーション64を格納することができる。セカンダリストレージデバイス74は、ハードディスクドライブ、フロッピディスクドライブ、CD-ROMドライブ、又は他のタイプの不揮発性データストレージを含むことができる。プロセッサ72は、メモリ62若しくはセカンダリストレージ74に格納された又はインターネット若しくは他のネットワーク60から受信されたアプリケーション(1以上)を実行する。入力デバイス70は、キーボード、マウス、カーソル制御デバイス、タッチスクリーン、マイクロホン、ディジタルカメラ、ビデオレコーダ、又はカムコーダなど、サーバ76に情報を入力する任意のデバイスを含むことができる。ディスプレイデバイス68は、たとえばコンピュータモニタ又はフラットスクリーンディスプレイなど、ビジュアル情報を提示する任意のタイプのデバイスを含むことができる。出力デバイス66は、プリンタなど、情報のハードコピーを提示する任意のタイプのデバイスを含むことができ、出力デバイスの他のタイプは、スピーカ又はオーディオの形で情報を提供する任意のデバイスを含む。

また、プロセッサ72は、本明細書で説明する機能を提供するために1以上のソフトウェアアプリケーション64を実行することができ、その処理は、コンピュータ又は他のマシンによる実行のために、ソフトウェアモジュールなどのソフトウェアで実施することができる。処理は、ユーザのコンピュータに関連するディスプレイデバイスでの表示のために本明細書に記載の及び他の形のウェブページを提供し、サポートすることができる。用語「スクリーン」は、情報又はフォームを表示する任意のビジュアル要素又はビジュアル要素の組合せを指し、例は、ディスプレイデバイス上のユーザインターフェース又はディスプレイデバイス上のウェブページ内若しくはウィンドウ内に表示される情報を含むが、これらに限定はされない。スクリーンは、たとえば、システムと対話するためにユーザによって使用されるアプリケーションに依存して、ハイパーテキストマークアップ言語(HTML)、拡張可能マークアップ言語(Extensible Markup Language)(XML)、又はディスプレイデバイスでのプレゼンテーション用の任意の他の適切な形のウェブページとしてフォーマットすることができる。

スクリーンは、情報を提供するため又は情報若しくはコマンドを受け取るために、下で説明するようにさまざまなセクションを含む。用語「スクリーンに関するセクション」は、場合によっては画面全体を含む、画面の特定の部分を指す。セクションは、たとえば情報若しくはコマンドを入力するため又は情報を取り出すか他のスクリーンにアクセスするために、選択される。選択は、たとえば、そのセクションを「クリックする」か「ダブルクリックする」ためにカーソル制御デバイスを使用することによって、行うことができる。代替案では、セクションを、一連のキーストロークを入力することによって、又は音声コマンド若しくはタッチスクリーンの使用を介してなどの他の形で、選択することができる。さらに、下で説明するスクリーンは、各スクリーン内の特定の配置及び特定の個数のセクションを示すが、他の配置が可能であり、スクリーン内の異なる個数のセクションを使用して、情報の表示及び情報又はコマンドの受取という同一の又は類似する機能を達成することができる。また、同一のセクションを、情報の表示とコマンドの受取との両方など、複数の機能を実行するのに使用することができる。

1つのサーバだけが示されているが、システム30は、ユーザをサポートする必要又は望みに応じて複数のサーバ76を使用することができ、特定のサーバの障害の場合のネットワークダウンタイムを避けるためにバックアップサーバ又は冗長サーバを使用することもできる。さらに、マシン37及びサーバ76が、さまざまなコンポーネントと共に示されているが、当業者は、これらのマシン及びサーバが、追加の又は異なるコンポーネントを含むことができることを理解するであろう。さらに、本発明と一貫する一実施態様の諸態様が、メモリに格納されるものとして説明されるが、当業者は、これらの態様を、ハードディスク、フロッピディスク、若しくはCD-ROMを含むセカンダリストレージデバイス、インターネット若しくは他のネットワークからの搬送波、又はRAM若しくはROMの他の形など、他のタイプのコンピュータプログラム製品又はコンピュータ可読媒体に格納し、又はそれから読み取ることもできることを理解するであろう。コンピュータ可読媒体は、特定の方法を実行するためにマシン37及びサーバ76などのコンピュータシステムを制御する命令を含むことができる。

例示的実施態様。このセクションは、例示的実施態様1から34までの形で、本発明の複数の例示的で非限定的な実施態様を提供する。

例示的実施態様1。飲料の開発及び製造を管理する方法であって、
複数の動作モードから選択された動作モードを使用して単一データレイヤ内で飲料の開発又は製造中の飲料に関する情報を記録するステップであって、複数の動作モード内の各動作モードが、情報が通過する状態及び情報を検証するルールに影響する、ステップと、
情報を複数のデータ次元内のデータ次元に割り当てるステップであって、複数のデータ次元が、(i)飲料の開発又は製造に使用される材料の材料タイプ、材料属性、及び/又は材料階層を格納する材料次元と、(ii)飲料の開発又は製造に参加する人の識別及び役割を格納する人次元と、(iii)飲料の開発又は製造に関する内部標準規格を格納するか、飲料の開発又は製造に関する政府の課す標準規格を格納する、標準規格次元と、(iv)飲料の開発又は製造に使用される有効限度、有効な値、機器特性、使用、及び/又は機器の可用性をセットする機器次元と、(v)飲料の開発又は製造に使用されるプロセスが行われる施設及び上記施設の属性を追跡する環境/施設次元と、(vi)飲料の開発又は製造に使用されるプロセスのタイプ、飲料の開発又は製造に使用されるプロセスのそれぞれに関連するワークフロー、及び飲料の開発又は製造に使用されるプロセスの階層を分類するプロセス次元とを備える、ステップと、
該複数のデータ次元内のデータ次元の間の複数の永久的相関を判定するステップであって、該複数の永久的相関が、(i)該材料次元と(ii)該人次元と(iii)該標準規格次元と(iv)該機器次元と(v)該環境/施設次元と(vi)該プロセス次元とからなる群からそれぞれ独立に選択される第1データ次元と第2データ次元との間の永久的相関を含み、該複数の永久的相関が、該飲料の該開発又は製造における時間及びイベントにまたがり、これによって、少なくとも1つの政府の課す規制標準規格とのコンプライアンスを確立する、ステップと、
複数の永久的相関を単一データレイヤに格納するステップと、
情報のコンテキストを判定するステップと、
コンテキストに応答して複数のデータ次元内のデータ次元の間で永久的相関を検索するステップと、
コンテキストを考慮して飲料の開発プロセス又は製造に関する情報を複数の次元及び複数の永久的相関から取り出すステップと、
飲料の開発又は製造の規制にかかわる規制機関への提出物に含めるために電子製品ヒストリレコード又は電子開発レコードを生成するのに該情報を使用するステップと
を含む、前記方法。

例示的実施態様2。方法が、さらに、前記規制機関への前記提出物に前記電子製品ヒストリレコード又は前記電子開発レコードを含めることを含む、例示的実施態様1記載の方法。

例示的実施態様3。コンテキストが、時間及びイベントにまたがる情報に対する変更を定義する、例示的実施態様1又は2記載の方法。

例示的実施態様4。材料次元が、さらに、飲料の管理のチェーンを含み、管理の該チェーンが、飲料の出発原料、飲料の出発試薬、飲料の開発に使用される溶剤、又は飲料の中間物を含む、例示的実施態様1から3のいずれか1つ記載の方法。

例示的実施態様5。プロセス次元に格納されるプロセスが、ブレンド、処方、又はレシピを含む、例示的実施態様1から4のいずれか1つ記載の方法。

例示的実施態様6。材料次元が、さらに、飲料を作るのに使用される材料のトレーサビリティを含む、例示的実施態様1から5のいずれか1つ記載の方法。

例示的実施態様7。情報が、飲料の開発又は製造に誰が参加したかの表示、飲料の開発又は製造に参加した人が飲料の開発又は製造で何を行ったかの表示、飲料の開発又は製造につながるイベントがどこで発生したかの表示、飲料の開発又は製造につながるイベントがいつ明らかになったかの表示、及び飲料の開発又は製造につながるイベントがどのように発生したかの表示を含む、例示的実施態様1から6のいずれか1つ記載の方法。

例示的実施態様8。情報が、飲料の開発又は製造に使用された構成物に関する各要求、飲料の開発又は製造に使用された構成物に関する各注文、飲料の開発又は製造に使用された各構成物の在庫、飲料の開発又は製造に使用された各材料の各ディスペンサル、飲料の開発又は製造に使用された各材料の各処分、及び飲料の開発又は製造に使用された各材料の各転送を含む、例示的実施態様1から6のいずれか1つ記載の方法。

例示的実施態様9。材料次元が、飲料の開発又は製造に使用される材料の材料状況、材料サインオフ、材料アラート、材料認証、材料電子承認、又は材料ハザードプロファイルを含む文書のチェーンを含む、例示的実施態様1から8記載の方法。

例示的実施態様10。材料次元が、飲料の開発又は製造に使用される各原材料の材料資格付与識別、使用テスト、及び仕様によって決定される飲料の品質を含む、例示的実施態様1から9のいずれか1つ記載の方法。

例示的実施態様11。方法が、情報内のオブジェクトに関連する各アラートをそれを介してユーザによって再検討できるアラートインターフェースを提供することをさらに含み、該ユーザが、アラートを肯定応答することができる、例示的実施態様1から10のいずれか1つ記載の方法。

例示的実施態様12。方法が、材料特性に基づいて飲料の開発又は製造に使用される各材料をソートすることをさらに含む、例示的実施態様1から11のいずれか1つ記載の方法。

例示的実施態様13。材料特性が、材料の評価日付又は純度である、例示的実施態様12記載の方法。

例示的実施態様14。機器次元が、飲料の開発又は製造に使用される機器の記録、飲料の開発又は製造に使用される機器のアイデンティティ、飲料の開発又は製造に使用される機器の特性、飲料の開発又は製造で借りられる機器の記録、飲料の開発又は製造で非作動状態にされる機器の記録、又は飲料の開発又は製造に使用される機器の保守記録若しくは清掃記録を含む、例示的実施態様1から13のいずれか1つ記載の方法。

例示的実施態様15。情報が、複数のオブジェクトを含み、該複数のオブジェクト内のオブジェクトが、作業注文、材料受取、又は機器スケジュールを含み、方法が、時間期間によってトリガされるアラートを割り当てることをさらに含む、例示的実施態様1から14のいずれか1つ記載の方法。

例示的実施態様16。材料次元が、飲料の開発又は製造中に使用される原材料及び出発原料が製造プロセスを介して移動されるときに、該原材料及び該出発材料の移動の記録を含む、例示的実施態様1から15のいずれか1つ記載の方法。

例示的実施態様17。方法が、
飲料の開発又は製造に使用される各構成物の在庫しきいレベルをセットする命令と、
材料の在庫が該在庫しきいレベル未満に下落するときに該材料の通知をトリガする命令とをさらに含む、
例示的実施態様1から16のいずれか1つ記載の方法。

例示的実施態様18。材料次元が、材料受取の表示、材料発行の表示、材料返却の表示、材料移動の表示、又は材料移動の検証を含み、該材料が、飲料の開発又は製造の原材料、中間材料、バルク材料、又は最終製品である、例示的実施態様1から17のいずれか1つ記載の方法。

例示的実施態様19。単一データレイヤが、単一データベース又は単一データ構造である、例示的実施態様1から18のいずれか1つ記載の方法。

例示的実施態様20。人次元が、デフォルト限度及び有効な値をセットする、例示的実施態様1から19のいずれか1つ記載の方法。

例示的実施態様21。複数の次元内の次元が、情報のタイプ、属性、及び状況を格納する、例示的実施態様1から20のいずれか1つ記載の方法。

例示的実施態様22。方法が、情報内のオブジェクトに関連する各アラートをそれを介してユーザによって再検討できるアラートインターフェースを提供することをさらに含み、該ユーザが、アラートを肯定応答することができる、例示的実施態様1から21のいずれか1つ記載の方法。

例示的実施態様23。プロセス次元が、飲料の医薬製造のステージ中に実行されるアクティビティレコード又は研究所分析レコードをさらに含む、例示的実施態様1から22のいずれか1つ記載の方法。

例示的実施態様24。プロセス次元が、飲料の開発又は製造内の各プロセスステップを含み、プロセスステップごとに、情報が、プロセスステップにかかわる人の識別、プロセスステップに使用される機器の識別、プロセスステップに使用される材料の識別、プロセスステップで従われる標準規格の識別、プロセスステップに使用される研究所の研究所条件の記述、又はプロセスステップに使用される施設位置の識別を含む、例示的実施態様1から23のいずれか1つ記載の方法。

例示的実施態様25。飲料が、医薬、生物薬剤、又は包括的合成物である、例示的実施態様1から24のいずれか1つ記載の方法。

例示的実施態様26。材料次元が、飲料の開発又は製造に使用される合成物の分析の証明書を含む、例示的実施態様1から25のいずれか1つ記載の方法。

例示的実施態様27。方法が、単一データレイヤに記録された情報に対して行われた変更の監査証跡を記録することをさらに含む、例示的実施態様1から26のいずれか1つ記載の方法。

例示的実施態様28。情報が、複数のオブジェクトを含み、該複数のオブジェクト内のオブジェクトが、作業注文、材料受取、又は機器スケジュールを含み、方法が、
単一データレイヤ内の該複数のオブジェクト内のオブジェクトの属性の変化によってトリガされるアラートを割り当てること
をさらに含む、例示的実施態様1から28のいずれか1つ記載の方法。

例示的実施態様29。属性の変化が、基準値との同等性、基準値との不等性、基準値を超える増加、基準値を下回る減少、値の範囲への変化、又は値の範囲から出る変化によって判定される、例示的実施態様28記載の方法。

例示的実施態様30。属性の変化が、ユーザアクションである、例示的実施態様28記載の方法。

例示的実施態様31。ユーザアクションが、オブジェクトのユーザ作成、オブジェクトのユーザ変更、又はオブジェクトのユーザ削除である、例示的実施態様30記載の方法。

例示的実施態様32。方法が、アラートにサブスクライブしたユーザにアラートをパブリッシュすることをさらに含む、例示的実施態様28記載の方法。

例示的実施態様33。アラートが、電子メール、ポケットベル、又はセル電話機によってユーザにパブリッシュされる、例示的実施態様32記載の方法。

例示的実施態様34。例示的実施態様1から33のいずれか一項記載の方法を実行するコンピュータシステム。

コンピュータシステム。本発明を、コンピュータ可読記憶媒体に埋め込まれたコンピュータプログラム機構を含むコンピュータプログラム製品として実施することができる。さらに、本発明の方法のいずれをも、1以上のコンピュータ又はコンピュータシステムで実施することができる。さらに、本発明の方法のいずれをも、1以上のコンピュータプログラム製品で実施することができる。本発明のいくつかの実施態様は、本明細書で開示される方法のいずれか又はすべてを実行する命令を符号化するか有するコンピュータシステム又はコンピュータプログラム製品を提供する。そのような方法/命令を、CD-ROM、DVD、磁気ディスクストレージ製品、又は任意の他のコンピュータ可読データストレージ製品若しくはプログラムストレージ製品に格納することができる。そのような方法を、ROM、1以上のプログラマブルチップ、又は1以上の特定用途向け集積回路(ASIC)などの永久ストレージに埋め込むこともできる。そのような永久ストレージを、サーバ、802.11アクセスポイント、802.11無線ブリッジ/ステーション、リピータ、ルータ、携帯電話機、又は他の電子デバイス内に局所化することができる。コンピュータプログラム製品に符号化されたそのような方法を、インターネットを介して又は他の形で、ディジタルに又は搬送波上でのいずれかでのコンピュータデータ信号(これにソフトウェアモジュールが埋め込まれる)の伝送によって、電子的に配布することもできる。

代替実施態様。本明細書で使用される用語及び説明は、例示のみのために示されるものであって、限定として意図されてはいない。当業者は、次の特許請求の範囲及びその同等物(次の特許請求の範囲では、すべての用語が、そうではないと示されない限り可能な最も広い意味で理解されなければならない)で定義される本発明の趣旨及び範囲の中で多数の変形形態が可能であることを認めるであろう。

Claims (34)

1. 飲料の開発及び製造を管理する方法であって、
   複数の動作モードから選択された動作モードを使用して単一データレイヤ内で該飲料の該開発又は製造中の該飲料に関する情報を記録するステップであって、該複数の動作モード内の各動作モードが、該情報が通過する状態及び該情報を検証するルールに影響する、ステップと、
   該情報を複数のデータ次元内のデータ次元に割り当てるステップであって、該複数のデータ次元が、(i)該飲料の該開発又は製造に使用される材料の材料タイプ、材料属性、及び/又は材料階層を格納する材料次元と、(ii)該飲料の該開発又は製造に参加する人の識別及び役割を格納する人次元と、(iii)該飲料の開発又は製造に関する内部標準規格を格納するか、該飲料の開発又は製造に関する政府の課す標準規格を格納する、標準規格次元と、(iv)該飲料の該開発又は製造に使用される有効限度、有効な値、機器特性、使用、及び/又は機器の可用性をセットする機器次元と、(v)該飲料の該開発又は製造に使用されるプロセスが行われる施設及び上記施設の属性を追跡する環境/施設次元と、(vi)該飲料の該開発又は製造に使用されるプロセスのタイプ、該飲料の該開発又は製造に使用される該プロセスのそれぞれに関連するワークフロー、及び該飲料の該開発又は製造に使用されるプロセスの階層を分類するプロセス次元とを備える、ステップと、
   該複数のデータ次元内のデータ次元の間の複数の永久的相関を判定するステップであって、該複数の永久的相関が、(i)該材料次元と(ii)該人次元と(iii)該標準規格次元と(iv)該機器次元と(v)該環境/施設次元と(vi)該プロセス次元とからなる群からそれぞれ独立に選択される第1データ次元と第2データ次元との間の永久的相関を含み、該複数の永久的相関が、該飲料の該開発又は製造における時間及びイベントにまたがり、これによって、少なくとも1つの政府の課す規制標準規格とのコンプライアンスを確立する、ステップと、
   該複数の永久的相関を該単一データレイヤに格納するステップと、
   該情報のコンテキストを判定するステップと、
   該コンテキストに応答して該複数のデータ次元内の該データ次元の間で該永久的相関を検索するステップと、
   該コンテキストを考慮して該飲料の開発プロセス又は製造に関する情報を該複数の次元及び該複数の永久的相関から取り出すステップと、
   飲料の該開発又は製造の該規制にかかわる規制機関への提出物に含めるために電子製品ヒストリレコード又は電子開発レコードを生成するのに該情報を使用するステップと
   を含む、前記方法。
2. 前記方法が、さらに、前記規制機関への前記提出物に前記電子製品ヒストリレコード又は前記電子開発レコードを含めることを含む、請求項1記載の方法。
3. 前記コンテキストが、時間及びイベントにまたがる前記情報に対する変更を定義する、請求項1又は2記載の方法。
4. 前記材料次元が、さらに、前記飲料の管理のチェーンを含み、管理の該チェーンが、前記飲料の出発原料、前記飲料の出発試薬、前記飲料の前記開発に使用される溶剤、又は前記飲料の中間物を含む、請求項1から3のいずれか一項記載の方法。
5. 前記プロセス次元に格納される前記プロセスが、ブレンド、処方、又はレシピを含む、請求項1から4のいずれか一項記載の方法。
6. 前記材料次元が、さらに、前記飲料を作るのに使用される材料のトレーサビリティを含む、請求項1から5のいずれか一項記載の方法。
7. 前記情報が、前記飲料の前記開発又は製造に誰が参加したかの表示、前記飲料の前記開発又は製造に参加した人が前記飲料の前記開発又は製造で何を行ったかの表示、前記飲料の前記開発又は製造につながるイベントがどこで発生したかの表示、前記飲料の前記開発又は製造につながるイベントがいつ明らかになったかの表示、及び前記飲料の前記開発又は製造につながるイベントがどのように発生したかの表示を含む、請求項1から6のいずれか一項記載の方法。
8. 前記情報が、前記飲料の前記開発又は製造に使用された構成物に関する各要求、前記飲料の前記開発又は製造に使用された構成物に関する各注文、前記飲料の前記開発又は製造に使用された各構成物の在庫、前記飲料の前記開発又は製造に使用された各材料の各ディスペンサル、前記飲料の前記開発又は製造に使用された各材料の各処分、及び前記飲料の前記開発又は製造に使用された各材料の各転送を含む、請求項1から6のいずれか一項記載の方法。
9. 前記材料次元が、前記飲料の前記開発又は製造に使用される材料の材料状況、材料サインオフ、材料アラート、材料認証、材料電子承認、又は材料ハザードプロファイルを含む文書のチェーンを含む、請求項1から8のいずれか一項記載の方法。
10. 前記材料次元が、前記飲料の前記開発又は製造に使用される各原材料の材料資格付与識別、使用テスト、及び仕様によって決定される前記飲料の品質を含む、請求項1から9のいずれか一項記載の方法。
11. 前記方法が、前記情報内のオブジェクトに関連する各アラートをそれを介してユーザによって再検討できるアラートインターフェースを提供することをさらに含み、該ユーザが、アラートを肯定応答することができる、請求項1から10のいずれか一項記載の方法。
12. 前記方法が、材料特性に基づいて前記飲料の前記開発又は製造に使用される各材料をソートすることをさらに含む、請求項1から11のいずれか一項記載の方法。
13. 前記材料特性が、前記材料の評価日付又は純度である、請求項12記載の方法。
14. 前記機器次元が、前記飲料の前記開発又は製造に使用される機器の記録、前記飲料の前記開発又は製造に使用される機器のアイデンティティ、前記飲料の前記開発又は製造に使用される機器の特性、前記飲料の前記開発又は製造で借りられる機器の記録、前記飲料の前記開発又は製造で非作動状態にされる機器の記録、又は前記飲料の前記開発又は製造に使用される機器の保守記録若しくは清掃記録を含む、請求項1から13のいずれか一項記載の方法。
15. 前記情報が、複数のオブジェクトを含み、該複数のオブジェクト内のオブジェクトが、作業注文、材料受取、又は機器スケジュールを含み、前記方法が、時間期間によってトリガされるアラートを割り当てることをさらに含む、請求項1から14のいずれか一項記載の方法。
16. 前記材料次元が、前記飲料の前記開発又は製造中に使用される原材料及び出発原料が製造プロセスを介して移動されるときに、該原材料及び該出発材料の移動の記録を含む、請求項1から15のいずれか一項記載の方法。
17. 前記方法が、
    前記飲料の前記開発又は製造に使用される各構成物の在庫しきいレベルをセットする命令と、
    材料の在庫が該在庫しきいレベル未満に下落するときに該材料の通知をトリガする命令とをさらに含む、請求項1から16のいずれか一項記載の方法。
18. 前記材料次元が、材料受取の表示、材料発行の表示、材料返却の表示、材料移動の表示、又は材料移動の検証を含み、該材料が、前記飲料の前記開発又は製造の原材料、中間材料、バルク材料、又は最終製品である、請求項1から17のいずれか一項記載の方法。
19. 前記単一データレイヤが、単一データベース又は単一データ構造である、請求項1から18のいずれか一項記載の方法。
20. 前記人次元が、デフォルト限度及び有効な値をセットする、請求項1から19のいずれか一項記載の方法。
21. 前記複数の次元内の次元が、前記情報のタイプ、属性、及び状況を格納する、請求項1から20のいずれか一項記載の方法。
22. 前記方法が、前記情報内のオブジェクトに関連する各アラートをそれを介してユーザによって再検討できるアラートインターフェースを提供することをさらに含み、該ユーザが、アラートを肯定応答することができる、請求項1から21のいずれか一項記載の方法。
23. プロセス次元が、前記飲料の医薬製造のステージ中に実行されるアクティビティレコード又は研究所分析レコードをさらに含む、請求項1から22のいずれか一項記載の方法。
24. 前記プロセス次元が、前記飲料の前記開発又は製造内の各プロセスステップを含み、プロセスステップごとに、前記情報が、前記プロセスステップにかかわる前記人の識別、前記プロセスステップに使用される前記機器の識別、前記プロセスステップに使用される前記材料の識別、前記プロセスステップで従われる前記標準規格の識別、前記プロセスステップに使用される研究所の研究所条件の記述、又は前記プロセスステップに使用される施設位置の識別を含む、請求項1から23のいずれか一項記載の方法。
25. 前記飲料が、医薬、生物薬剤、又は包括的合成物である、請求項1から24のいずれか一項記載の方法。
26. 前記材料次元が、前記飲料の前記開発又は製造に使用される合成物の分析の証明書を含む、請求項1から25のいずれか一項記載の方法。
27. 前記方法が、前記単一データレイヤに記録された前記情報に対して行われた変更の監査証跡を記録することをさらに含む、請求項1から26のいずれか一項記載の方法。
28. 前記情報が、複数のオブジェクトを含み、該複数のオブジェクト内のオブジェクトが、作業注文、材料受取、又は機器スケジュールを含み、前記方法が、
    前記単一データレイヤ内の該複数のオブジェクト内のオブジェクトの属性の変化によってトリガされるアラートを割り当てること、
    をさらに含む、請求項1から28のいずれか一項記載の方法。
29. 前記属性の前記変化が、基準値との同等性、基準値との不等性、基準値を超える増加、基準値を下回る減少、値の範囲への変化、又は値の範囲から出る変化によって判定される、請求項28記載の方法。
30. 前記属性の前記変化が、ユーザアクションである、請求項28記載の方法。
31. 前記ユーザアクションが、オブジェクトのユーザ作成、オブジェクトのユーザ変更、又はオブジェクトのユーザ削除である、請求項30記載の方法。
32. 前記方法が、前記アラートに承諾したユーザに前記アラートを公開することをさらに含む、請求項28記載の方法。
33. 前記アラートが、電子メール、ポケットベル、又はセル電話機によって前記ユーザに公開される、請求項32記載の方法。
34. 請求項1から33のいずれか一項記載の方法を実行するコンピュータシステム。

Images