JP4002436B2 - 業務処理管理システム及びその方法、サーバ装置並びにプログラム - Google Patents
業務処理管理システム及びその方法、サーバ装置並びにプログラム Download PDFInfo
- Publication number
- JP4002436B2 JP4002436B2 JP2001399528A JP2001399528A JP4002436B2 JP 4002436 B2 JP4002436 B2 JP 4002436B2 JP 2001399528 A JP2001399528 A JP 2001399528A JP 2001399528 A JP2001399528 A JP 2001399528A JP 4002436 B2 JP4002436 B2 JP 4002436B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- business
- demand
- key
- supply
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 580
- 238000012545 processing Methods 0.000 title claims description 48
- PWPJGUXAGUPAHP-UHFFFAOYSA-N lufenuron Chemical compound C1=C(Cl)C(OC(F)(F)C(C(F)(F)F)F)=CC(Cl)=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F PWPJGUXAGUPAHP-UHFFFAOYSA-N 0.000 title 1
- 230000008569 process Effects 0.000 claims description 448
- 238000007726 management method Methods 0.000 claims description 54
- 238000011144 upstream manufacturing Methods 0.000 claims description 7
- 230000010365 information processing Effects 0.000 claims description 6
- 230000000875 corresponding effect Effects 0.000 description 51
- 238000004519 manufacturing process Methods 0.000 description 31
- 238000010586 diagram Methods 0.000 description 22
- 230000008859 change Effects 0.000 description 14
- 238000012546 transfer Methods 0.000 description 13
- 230000004044 response Effects 0.000 description 12
- 238000007689 inspection Methods 0.000 description 10
- 238000013439 planning Methods 0.000 description 10
- 238000004891 communication Methods 0.000 description 7
- 238000012384 transportation and delivery Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 5
- 230000000694 effects Effects 0.000 description 5
- 239000000463 material Substances 0.000 description 5
- 230000007704 transition Effects 0.000 description 5
- 238000011960 computer-aided design Methods 0.000 description 4
- 238000013461 design Methods 0.000 description 4
- 230000006872 improvement Effects 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 230000001276 controlling effect Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 238000010276 construction Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000007639 printing Methods 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 238000013068 supply chain management Methods 0.000 description 2
- 238000010977 unit operation Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
Landscapes
- General Factory Administration (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
【発明の属する技術分野】
本発明は生産管理や販売・物流などにかかる業務処理をコンピュータによって管理する技術に関し、特に業務担当者間で受け渡される情報及び情報の流れをコンピュータによって管理するシステム及びその方法に関する。
【0002】
【従来の技術】
一般に企業等における業務プロセスは、複数の作業工程の一連の流れで構成され、仕事に必要な情報が作業工程間で適宜伝達されることにより業務が遂行される。このような仕事に必要な情報の伝達をコンピュータによって管理する場合、業務プロセスを構成する複数の作業工程間の情報の流れを如何にして管理するか、或る作業工程から次の作業工程へ受け渡される仕事に関する情報を如何にして管理するか、関連する仕事どうしを如何に関連付けるかが重要である。
【0003】
複数の作業工程間における情報の伝達をコンピュータによって管理する技術の一例が特開平10−214113号公報(以下、文献1と称す)に示されている。この文献1に記載された従来技術では、業務プロセスを構成する複数の作業工程のシーケンスを、各作業工程に1対1に対応付けたレコードを工程順に並べた状態遷移ルールによって定義し、更に各レコードにおいて当該作業工程でデータ入力を完了すべきデータ項目を定義する。また、業務プロセスを構成する作業工程に関連する全てのデータ項目の内容を掲示板データベースのテーブルに集約し、関連する全ての担当者がこのデータベースを掲示板の形式で共有することにより、作業工程間で授受されるデータを管理する。掲示板データベースは、少なくとも1組の掲示板データを保持する。1組の掲示板データは業務処理システム上で処理される個々の一連の業務に対応して形成される。掲示板データベースはまた、現在作業中の状態にある作業工程も管理する。コンピュータは、掲示板データベース及び状態遷移ルールを参照して、原則として現在作業中の工程に関するデータのみを受け付けることで、作業工程間の情報の流れが事前に定義された順序通りになるように制御する。
【0004】
【発明が解決しようとする課題】
近年、激変する事業環境の影響を受け、頻繁に実施されるBPR(Business Process Reengineering;ビジネスプロセスリエンジニアリング)や、生産の現場で日々行われる「カイゼン」と呼ばれる小集団活動による業務プロセスの変化に合わせて、業務処理管理システムを機敏に変更させる必要性が強く望まれている。特に、ハイテク企業の生産システムにおいては、商品のライフサイクルの短命化とあわせ、日々が業務プロセスの変化の連続であり、今後、この傾向は一層強まる状況にあるため、業務処理管理システムの対応の遅れは、プロセス改善の足かせとなる。しかるに文献1に記載の従来技術では、業務プロセスの変更に機敏に対応することが容易でないという課題がある。
【0005】
それは次の理由による。文献1に記載の従来技術では、掲示板データベースにおいて関連付けて記憶することができる情報は、個々の掲示板データを構成する情報どうし、つまり状態遷移ルールによって定義された業務プロセスを構成する複数の作業工程のシーケンスにかかわる一連のデータどうしに限られ、異なる掲示板データどうし、つまり業務プロセスどうしは関連付けることはできない。これは、関連する仕事は1つの掲示板データに集約し、必要な全ての情報の流れを1つの掲示板データで管理しなければならないことを意味する。従って、或る製品Aを部品a1、a2から製造する生産システムを考えた場合、製品Aに関連する一連の作業工程および部品a1、a2に関連する一連の作業工程を全て含む一連の作業工程を事前に定義し、この一連の作業工程の情報の流れを1組の掲示板データで管理する必要がある。このため、製品A、部品a1、a2の何れかの一連の作業工程が変更されると、他の部品や製品の作業工程に影響がなくても、定義した一連の作業工程全体の再定義が必要になり、その変更に多大な時間と労力が必要となる。
【0006】
文献1に記載の従来技術が業務プロセスの変更に機敏に対応することが容易でない別の理由は、文献1に記載の従来技術は、業務プロセス毎にそれを構成する全ての作業工程の流れを一連の流れとして状態遷移ルールによって定義することで作業工程間の情報の流れを管理しているため、複数の業務プロセスで共通に使われる作業工程に変更があったとき、変更すべき状態遷移ルールが多岐にわたり、変更に多大な時間と労力が必要となるためである。例えば、作業工程k1→作業工程k2→作業工程k3から構成される一連の作業工程を全ての業務プロセスが含む場合、従来技術では、各業務プロセスの作業工程の流れの定義中に、「作業工程k1→作業工程k2→作業工程k3」の定義が含まれるため、業務改善などにより当該一連の作業工程が「作業工程k1→作業工程k3」に変更されると、全業務プロセスの作業工程の定義を修正する必要がある。
【0007】
文献1に記載の従来技術が業務プロセスの変更に機敏に対応することが容易でない更に別の理由は、一連の業務プロセスに関連する全てのデータ項目の内容を掲示板データベースのテーブルに格納しているため、或る業務プロセスの変更によって既存の掲示板データベースに存在しないデータ項目が必要となった場合、そのようなデータ項目を必要とする業務プロセスがほんの一部のプロセスであっても、新たなデータ項目をデータベースのテーブルへ追加する必要があり、そのための大掛かりな作業が必要になるためである。
【0008】
また、文献1に記載の従来技術では、各担当者から掲示板データベースに入力されたデータの履歴を記録しており、必要に応じて入力済のデータを参照することで、業務の現在の状況や業務分析等が或る程度は行えるようになっている。しかし、掲示板データベースに入力されるデータは、主に仕事の依頼に関するデータに限定されており、依頼に対する実績報告が必ずしも記録されていないために充分な現状把握や業務分析は行えないという課題もある。
【0009】
本発明はこのような事情に鑑みて提案されたものであり、その目的は、業務プロセスの変更に対して機敏に変更可能な業務処理管理システム及びその方法を提供することにある。
【0010】
本発明の別の目的は、業務の現在状況の把握や業務分析をより詳しく行うことができる業務処理管理システム及びその方法を提供することにある。
【0011】
【課題を解決するための手段】
本発明の第1の業務処理管理システムは、業務プロセスを構成する複数の作業工程間で受け渡される情報及び情報の流れを管理する業務処理管理システムであって、一連の作業工程からなる単位業務における作業工程間で受け渡す個々の情報毎に、その情報の種別を示すデマンド/サプライ種と業務単位を示す手順区分とその情報の直前に受け渡される情報の種別を示す親デマンド/サプライ種とを定義することにより、各単位業務における情報の流れを定義した業務手順マスタ、および、単位業務間をまたがる情報の流れ毎に、情報の流れの上流側の単位業務と情報の種別を示す親手順区分と親デマンド/サプライ種、情報の流れの下流側の単位業務と情報の種別を示す手順区分とデマンド/サプライ種を定義することにより、単位業務間の情報の流れを定義した業務フローマスタを記憶し、前記業務手順マスタと前記業務フローマスタとによって、業務プロセスを構成する一連の作業工程間の情報の流れを定義する業務プロセス定義部と、作業工程間で受け渡される情報であって、自情報を一意に識別するための自キーと、一連の作業工程の情報の流れにおける自情報の直前の情報を識別するための親キーと、関連する他の業務プロセスの情報の自キーの値を持つ用途キーとを持つ情報を記憶する共有データベースと、クライアント端末から前記共有データベースに対する仕事に必要な情報の入出力を制御するサーバであって、前記クライアント端末から登録を要求された情報を受信し、受信した情報に親キーが設定されているかどうかを判定し、親キーが設定されていない場合には、受信した情報に含まれる手順区分およびデマンド/サプライ種で特定される情報が業務プロセスの最初に受け渡される情報として前記業務手順マスタに定義されていることを条件に今回登録要求された情報の登録を行い、親キーが設定されている場合には、該設定されている親キーと同じ内容を自キーに持つ情報を前記共有データベースから検索し、該検索に成功し且つ該検索した情報の次に受け渡される情報が今回登録要求された情報に含まれる手順区分およびデマンド/サプライ種で特定される情報であることが前記業務手順マスタおよび前記業務フローマスタを参照して確かめられたことを条件に今回登録要求された情報の登録を行うことにより、前記業務プロセス定義部に定義された業務プロセスを構成する一連の作業工程間の情報の流れ通りの順序で情報が入力されるように制御し、且つ、前記クライアント端末から受信した検索キーを自キーに持つ情報と前記検索キーを用途キーに持つ情報とを前記共有データベースから検索して、検索結果を前記クライアント端末へ送信するサーバとを備えたことを特徴とする。
【0013】
本発明の第2の業務処理管理システムは、第1の業務処理管理システムにおいて、前記共有データベースは、作業工程間で受け渡される情報の情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有している。
【0014】
本発明の第3の業務処理管理システムは、第2の業務処理管理システムにおいて、業務プロセスを構成する複数の作業工程間で受け渡される情報は、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報とを含み、前記共通テーブルは、前記デマンド情報を格納するデマンドテーブルと前記サプライ情報を格納するサプライテーブルとで構成されている。
【0015】
本発明の第4の業務処理管理システムは、第3の業務処理管理システムにおいて、前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、少なくとも、誰が(Who)に相当する情報要素を格納するデータ項目と、誰に(Whom)に相当する情報要素を格納するデータ項目と、何を(What)に相当する情報要素を格納するデータ項目と、どうする(How−Do)に相当する情報要素を格納するデータ項目とを備えている。
【0016】
本発明の第5の業務処理管理システムは、第4の業務処理管理システムにおいて、前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、更に、いつ(When)に相当する情報要素を格納するデータ項目、どこに(Where)に相当する情報要素を格納するデータ項目、いくつ(How−Many)に相当する情報要素を格納するデータ項目、いつまでに(How−Long)に相当する情報要素を格納するデータ項目、いくらで(How−Much)に相当する情報要素を格納するデータ項目のうち、少なくとも1つのデータ項目を備えている。
【0017】
また、本発明の第1の業務処理管理方法は、一連の作業工程からなる単位業務における作業工程間で受け渡す個々の情報毎に、その情報の種別を示すデマンド/サプライ種と業務単位を示す手順区分とその情報の直前に受け渡される情報の種別を示す親デマンド/サプライ種とを定義することにより、各単位業務における情報の流れを定義した業務手順マスタ、および、単位業務間をまたがる情報の流れ毎に、情報の流れの上流側の単位業務と情報の種別を示す親手順区分と親デマンド/サプライ種、情報の流れの下流側の単位業務と情報の種別を示す手順区分とデマンド/サプライ種を定義することにより、単位業務間の情報の流れを定義した業務フローマスタを記憶し、前記業務手順マスタと前記業務フローマスタとによって、業務プロセスを構成する一連の作業工程間の情報の流れを定義する業務プロセス定義部と、作業工程間で受け渡される情報であって、自情報を一意に識別するための自キーと、一連の作業工程の情報の流れにおける自情報の直前の情報を識別するための親キーと、関連する他の業務プロセスの情報の自キーの値を持つ用途キーとを持つ情報を記憶する共有データベースと、クライアント端末から前記共有データベースに対する仕事に必要な情報の入出力を制御するサーバと、前記サーバにネットワーク経由で接続されたクライアント端末とから構成され、業務プロセスを構成する複数の作業工程間で受け渡される情報及び情報の流れを管理する情報処理システムにおける業務処理管理方法であって、前記サーバにおいて、前記クライアント端末から登録を要求された情報を受信し、受信した情報に親キーが設定されているかどうかを判定し、親キーが設定されていない場合には、受信した情報に含まれる手順区分およびデマンド/サプライ種で特定される情報が業務プロセスの最初に受け渡される情報として前記業務手順マスタに定義されていることを条件に今回登録要求された情報の登録を行い、親キーが設定されている場合には、該設定されている親キーと同じ内容を自キーに持つ情報を前記共有データベースから検索し、該検索に成功し且つ該検索した情報の次に受け渡される情報が今回登録要求された情報に含まれる手順区分およびデマンド/サプライ種で特定される情報であることが前記業務手順マスタおよび前記業務フローマスタを参照して確かめられたことを条件に今回登録要求された情報の登録を行うことにより、前記業務プロセス定義部に定義された業務プロセスを構成する一連の作業工程間の情報の流れ通りの順序で情報が入力されるように制御するステップと、前記クライアント端末から受信した検索キーを自キーに持つ情報と前記検索キーを用途キーに持つ情報とを前記共有データベースから検索して、検索結果を前記クライアント端末へ送信するステップとを含んでいる。
【0019】
本発明の第2の業務処理管理方法は、第1の業務処理管理方法において、前記共有データベースは、作業工程間で受け渡される情報の情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有している。
【0020】
本発明の第3の業務処理管理方法は、第2の業務処理管理方法において、業務プロセスを構成する複数の作業工程間で受け渡される情報は、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報とを含み、前記共通テーブルは、前記デマンド情報を格納するデマンドテーブルと、前記サプライ情報を格納するサプライテーブルとで構成される。
【0021】
本発明の第4の業務処理管理方法は、第3の業務処理管理方法において、前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、少なくとも、誰が(Who)に相当する情報要素を格納するデータ項目と、誰に(Whom)に相当する情報要素を格納するデータ項目と、何を(What)に相当する情報要素を格納するデータ項目と、どうする(How−Do)に相当する情報要素を格納するデータ項目とを備えるようにしている。
【0022】
本発明の第5の業務処理管理方法は、第4の業務処理管理方法において、前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、更に、いつ(When)に相当する情報要素を格納するデータ項目、どこに(Where)に相当する情報要素を格納するデータ項目、いくつ(How−Many)に相当する情報要素を格納するデータ項目、いつまでに(How−Long)に相当する情報要素を格納するデータ項目、いくらで(How−Much)に相当する情報要素を格納するデータ項目のうち、少なくとも1つのデータ項目を備えるようにしている。
【0023】
【作用】
第1の業務処理管理システム及び方法にあっては、業務プロセスを構成する一連の作業工程間で受け渡される情報を、当該業務プロセスを構成する一連の作業工程間の情報の流れの順だけでなく、関連する他の業務プロセスに関連付けて共有データベースに記憶できるため、業務プロセスの単位を細分化し、階層的に管理することができる。たとえば或る製品Aを部品a1、a2から製造する生産システムを考えた場合、製品Aに関連する仕事の一連の作業工程、部品a1に関連する仕事の一連の作業工程、部品a2に関連する仕事の一連の作業工程をそれぞれ業務プロセスとして定義すれば、各業務プロセスの一連の作業工程間の情報の流れ順に仕事に必要な情報を管理しつつ、部品a1および部品a2にかかる情報と製品Aにかかる情報とを関連付け、全体として或るまとまった業務処理にかかる情報を管理することができる。こうすると、製品A、部品a1、a2の何れかの一連の作業工程が変更された場合には、変更された一連の作業工程を再定義するだけで済み、業務プロセスの変更に伴う定義情報の変更箇所を局所化でき、迅速な対応が可能となる。また、関連付けを用途キーによって行うため、製品Aの情報に部品a1、a2の情報のコピーを付随させ、逆に部品a1、a2の情報に製品Aの情報のコピーを付随させる場合のような重複した情報の記憶が不要となる。
【0024】
また第1の業務処理管理システム及び方法にあっては、業務プロセスを構成する一連の作業工程間の情報の流れを、一連の作業工程からなる単位業務における情報の流れを定義した業務手順マスタと、単位業務間の情報の流れを定義した業務フローマスタとによって定義するため、単位業務内における情報の流れの変更は業務手順マスタの定義を変更することで対処でき、単位業務間の情報の流れの変更は業務フローマスタの定義を変更することで対処できる。従って、業務プロセスの変更に伴う定義情報の変更箇所をより局所化でき、迅速な対応が可能となる。
【0025】
例えば、作業工程p1→作業工程k1→作業工程k2→作業工程k3→作業工程p2からなる業務プロセスP、作業工程q1→作業工程k1→作業工程k2→作業工程k3→作業工程q2からなる業務プロセスQがあるとき、「作業工程p1→作業工程p2」、「作業工程q1→作業工程q2」、「作業工程k1→作業工程k2→作業工程k3」をそれぞれ1つの業務単位X、Y、Zとして、各業務単位における情報の流れを業務手順マスタに定義する。また、業務単位Xと業務単位Zとの情報の流れ「作業工程p1→作業工程k1、作業工程k3→作業工程p2」、業務単位Yと業務単位Zとの情報の流れ「作業工程q1→作業工程k1、作業工程k3→作業工程q2」を業務フローマスタに定義する。こうすると、業務改善などにより業務単位Zの作業工程が「作業工程k1→作業工程k3」に変更されても、業務単位Zの業務手順定義だけを変更するだけで対処できる。また、業務プロセスP、Qにおいて作業工程p2、q2に続いて別の作業工程を行うように業務プロセスが変更された場合、別の作業工程を例えば「作業工程r1→作業工程r2」とすると、これを1つの業務単位Wとして業務手順マスタに定義し、業務単位Pと業務単位Wとの情報の流れ「作業工程p2→作業工程r1」、業務単位Qと業務単位Wとの情報の流れ「作業工程q2→作業工程r1」を業務手順に定義することで、新規な作業工程の追加にも容易に対処することができる。更に、業務プロセスP、Qの何れか一方または双方で業務単位Zを必要としなくなった場合、業務フローマスタから業務単位X、Yと業務単位Zとの情報の流れの定義を削除することで容易に対処することができる。
【0026】
第2の業務処理管理システム及び方法にあっては、共有データベースが、作業工程間で受け渡されるデータの情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有しているため、共通情報要素以外の個別情報要素が新たに発生した場合、プロパティテーブルを追加するだけで対処可能となり、本体部分である共通テーブルに新規なデータ項目を追加するような大掛かりな作業が不要となる。
【0027】
第3の業務処理管理システム及び方法にあっては、業務プロセスを構成する複数の作業工程間で受け渡される情報が、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報とを含み、デマンド情報はデマンドテーブルを通じて受け渡され、サプライ情報はサプライテーブルを通じて受け渡される。このように、仕事の依頼に関するデータ(デマンド情報)のみならず、その仕事の実績報告(サプライ情報)をも保存して管理することで、現状把握や業務分析がより詳細に行える。
【0028】
第4の業務処理管理システム及び方法にあっては、前記デマンドテーブル及び前記サプライテーブルのデータ項目が、誰が(Who)に相当する情報要素を格納するデータ項目、誰に(Whom)に相当する情報要素を格納するデータ項目、何を(What)に相当する情報要素を格納するデータ項目、どうする(How−Do)に相当する情報要素を格納するデータ項目として汎用的なデータ項目とされ、また第5の業務処理管理システムにあっても、いつ(When)に相当する情報要素を格納するデータ項目、どこに(Where)に相当する情報要素を格納するデータ項目、いくつ(How−Many)に相当する情報要素を格納するデータ項目、いつまでに(How−Long)に相当する情報要素を格納するデータ項目、いくらで(How−Much)に相当する情報要素を格納するデータ項目として汎用的なデータ項目とされているため、事前に想定した特定の業務用だけでなく、任意の業務に汎用的に使用することが可能となる。
【0029】
【発明の実施の形態】
次に本発明の実施の形態の例について図面を参照して詳細に説明する。
【0030】
図1は本発明の一実施の形態にかかる業務処理管理システムの構成図である。この例の業務処理管理システムは、サーバ1と、このサーバ1にネットワーク2を通じて接続された複数のクライアント端末3とを含んで構成され、サーバ1には、共有データベース4及び業務プロセス定義部5が接続され、各クライアント端末3には表示装置6及び入力装置7が接続されている。また、サーバ1は、ファイル管理部11、処理部12及び通信制御部13を備え、各クライアント端末3は、通信制御部31及びユーザ入出力部32を備えている。
【0031】
業務プロセス定義部5は、業務プロセスを構成する一連の作業工程間で受け渡される情報の種類の定義及びその情報の流れを定義する記憶装置であり、デマンドサプライマスタ51、業務手順マスタ52及び業務フローマスタ53を有する。本実施の形態では、業務プロセスを構成する複数の作業工程間で受け渡される情報には、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報との2通りがあり、デマンド情報及びサプライ情報にはそれぞれ複数の種類がある。デマンド情報の種類をデマンド種、サプライ情報の種類をサプライ種と呼ぶ。同じ種類のデマンド情報とサプライ情報とはペアになる。デマンドサプライマスタ51は、業務プロセスで必要な全てのデマンド情報及びサプライ情報の種類(デマンド種、サプライ種)を定義するマスタファイルである。このデマンドサプライマスタ51に定義されない種類のデマンド情報及びサプライ情報の登録はサーバ1によって拒否される。
【0032】
業務手順マスタ52及び業務フローマスタ53は、業務プロセスを構成する一連の作業工程間で受け渡される情報の流れを定義するマスタファイルである。このうち、業務手順マスタ52は、一連の作業工程からなる単位業務における情報の流れを定義し、業務フローマスタ53は、単位業務間の情報の流れを定義する。単位業務は、1つの業務部門内における一連の作業工程に限定されず、複数の業務部門にまたがる一連の作業工程とすることができる。
【0033】
共有データベース4は、作業工程間で受け渡されるデータを記憶するデータベースである。或る業務を行う担当者がクライアント端末3からサーバ1を通じて業務上のデータを共有データベース4に登録し、別の業務を行う担当者がクライアント端末3からサーバ1を通じて共有データベース4に登録されたデータを参照することで、作業工程間でのデータの受け渡しが行われる。本実施の形態では、共有データベース4は、作業工程間で受け渡されるデータの情報要素のうち、全ての作業工程で共通な共通情報要素を記憶する共通テーブル41と、それ以外の個別情報要素を記憶する1以上のプロパティテーブル42とを有している。また、共通テーブル41はデマンドテーブル43及びサプライテーブル44に分けられている。デマンドテーブル43には、デマンド情報を構成する情報要素のうちの共通情報要素が格納され、サプライテーブル44には、サプライ情報を構成する情報要素のうちの共通情報要素が格納される。
【0034】
デマンドテーブル43及びサプライテーブル44は、データ項目として、少なくとも、誰が(Who)に相当する情報要素を格納するデータ項目と、誰に(Whom)に相当する情報要素を格納するデータ項目と、何を(What)に相当する情報要素を格納するデータ項目と、どうする(How−Do)に相当する情報要素を格納するデータ項目とを備える。これは、一般に仕事を依頼する場合、最低限、誰が、誰に、何を、どうするの4要素を伝達すれば良く、依頼された仕事の実績を報告するには、誰が、誰に、何を、どうしたの4要素を伝達すれば良いことに基づく。但し、依頼や報告をより詳細に行うために、デマンドテーブル43及びサプライテーブル44は、更に、いつ(When)に相当する情報要素を格納するデータ項目、どこに(Where)に相当する情報要素を格納するデータ項目、いくつ(How−Many)に相当する情報要素を格納するデータ項目、いつまでに(How−Long)に相当する情報要素を格納するデータ項目、いくらで(How−Much)に相当する情報要素を格納するデータ項目のうち、少なくとも1つのデータ項目を備えるようにしても良い。また、デマンドテーブル43とサプライテーブル44とが同じデータ項目を持っていても良いし、異なるデータ項目を持っていても良い。
【0035】
また、デマンドテーブル43及びサプライテーブル44は、格納するデマンド情報及びサプライ情報を一連の作業工程間の情報の流れの順に関連付けて記憶するためのキーの項目を有している。このためのキーには、自データを一意に識別する自キーと、一連の作業工程の情報の流れにおける自データの直前のデータを識別するための親キーとの2種類がある。或るデータに付された自キーと同じ内容の親キーを持つデータを探索することで、一連の作業工程の情報の流れ方向にデマンド情報、サプライ情報を辿ることができ、反対に、或るデータに付された親キーと同じ内容の自キーを持つデータを探索することで、一連の作業工程の情報の流れと逆方向にデマンド情報、サプライ情報を辿ることができる。また、プロパティテーブル42に格納される個別情報要素は、その個別情報要素がどのデマンド情報、サプライ情報の属性(プロパティ)であるか、つまり、どの共通情報要素と関連しているかを示すキーの項目を有している。キーの値としては、関連する共通情報要素に付加された自キーの値が使われる。
【0036】
また、デマンドテーブル43は、更に、或る業務プロセスにかかるデマンド情報を他の業務プロセスに関連付けるための用途キーを有している。用途キーには、関連する他の業務プロセスのデマンド情報に設定された自キーの値が設定される。或る業務プロセスPのデマンド情報に付された自キーと同じ内容の用途キーを持つデマンド情報を探索することで、業務プロセスPの下位階層の業務プロセスQを知ることができ、反対に、業務プロセスQのデマンド情報に付された用途キーと同じ内容の自キーを持つデマンド情報を探索することで、業務プロセスQの上位階層の業務プロセスPを知ることができる。
【0037】
以上の共有データベース4及び業務プロセス定義部5は、サーバ1に接続される記憶装置上に格納される。これらの共有データベース4や各マスタへのアクセスの管理は、サーバ1のファイル管理部11によって行われる。なお、共有データベース4及び業務プロセス定義部5並びにファイル管理部11をネットワークを介してサーバ1に接続される別のサーバによって実現しても良い。
【0038】
クライアント端末3の表示装置6は、共有データベース4に入力すべきデータや共有データベース4から出力したデータ等を表示するCRTディスプレイ、LCD等で構成される。入力装置7は、作業工程間で受け渡すべきデータや各種のコマンド等を入力する装置であり、キーボードやマウス等で構成される。ユーザ入出力部32は、グラフィカルユーザインタフェースを実現する処理部であり、共有データベース4から入力したデータを予め画面設計された表示画面の様式に合わせて表示し、また表示画面上で作成されたデータを共有データベース4の格納形式に合わせてサーバ1へ送信する。通信制御部31は、ネットワーク2を介してサーバ1との間で行われるデータ等の送受信を制御する。
【0039】
サーバ1の処理部12は、クライアント端末3からの要求に従って共有データベース4に対するデータの入出力を制御する制御部である。出力に際しては、クライアント端末3から要求されたデータを共有データベース4から取り出し、ネットワーク2経由で要求元のクライアント端末3へ送信する。入力に際しては、クライアント端末3から要求されたデータをネットワーク2経由で受信し、共有データベース4に登録する。この際、業務プロセス定義部5に定義された業務プロセスを構成する一連の作業工程間の情報の流れ通りの順序でデータが入力されるように制御することで、作業工程間のデータの受け渡しが、事前に定義された順番通りに行われることを保証する。また、クライアント端末3から入力を要求されたデータの情報要素のうち共通情報要素は共通テーブル41に登録する。共通テーブル41はデマンドテーブル43とサプライテーブル44とに分かれているため、デマンド作業工程から出された共通情報要素はデマンドテーブル43に、サプライ作業工程から出された共通情報要素はサプライテーブル44に、それぞれ登録される。クライアント端末3から入力を要求されたデータの情報要素のうち個別情報要素は、該当するプロパティテーブル42に登録する。サーバ1の通信制御部13は、ネットワーク2を介してクライアント端末3との間に行われるデータ等の送受信を制御する。
【0040】
サーバ1及びクライアント端末3は、パーソナルコンピュータ、ワークステーション等の情報処理装置によって構成される。サーバ1上のファイル管理部11、処理部12及び通信制御部13、クライアント端末3上の通信制御部31及びユーザ入出力部32は、サーバ1及びクライアント端末3を構成する情報処理装置のハードウェアによって、またその記憶装置に格納されるプログラムを実行することによって実現される。
【0041】
図2は本実施の形態にかかる業務処理管理システムのより詳しい説明を行うために便宜上想定した業務プロセスのモデルを示す。A、B、C、D、Eの5つの作業工程があり、これら複数の作業工程間でD1〜D3、S1〜S3のデータが受け渡される。このうち、D1〜D3はそれぞれ異なる種類のデマンド情報を示し、S1〜S3はそれぞれ異なる種類のサプライ情報を示す。また、D1とS1、D2とS2、D3とS3はそれぞれペアとなるデマンド情報及びサプライ情報である。業務プロセスとしては、作業工程Aから始まる業務プロセスPと、作業工程Bから始まる業務プロセスQとが存在し、双方の業務プロセスP、Qは同じ作業工程C、D、Eを含んでいる。業務プロセスPでは、作業工程A→作業工程C→作業工程D→作業工程C→作業工程E→作業工程C→作業工程Aの順で業務が行われ、業務プロセスQでは、作業工程B→作業工程C→作業工程D→作業工程C→作業工程E→作業工程C→作業工程Bの順で業務が行われる。一連の作業工程中に同じ作業工程が現れているが、これは1つの作業工程が幾つかの作業工程に分かれていることを想定している。また、一連の作業工程からなる単位業務として、図2に示す単位業務X、Y、Zを想定する。さらに、業務プロセスPは業務プロセスQの上位階層のプロセスとする。上位階層のプロセスとは、自プロセスの業務を遂行するに際して下位階層のプロセスの業務を必要とするプロセスを意味する。例えば、部品a1で作られる製品Aがあるとき、製品Aにかかる業務プロセスは部品a1にかかる業務プロセスの上位階層のプロセスであり、部品a1にかかる業務プロセスは製品Aにかかる業務プロセスの下位階層のプロセスである。
【0042】
図3はデマンドサプライマスタ51の論理的な構成例を示す。図3に示すように、デマンドサプライマスタ51には、デマンド種51−1とサプライ種51−2とがペアで定義される。図2のモデルの場合、D1とS1、D2とS2、D3とS3がそれぞれのレコードR11〜R13に登録される。
【0043】
図4は業務手順マスタ52の論理的な構成例を示す。図4に示すように、業務手順マスタ52には、各単位業務における作業工程間で受け渡す個々のデマンド情報及びサプライ情報毎に、そのデマンド/サプライ種52−3と、手順区分52−1、親デマンド/サプライ種52−2、順序52−4、種別52−5とがそれぞれのレコードR21〜R28に定義される。手順区分52−1は単位業務を一意に識別する識別子であり、親デマンド/サプライ種52−2は当該単位業務内における当該デマンド/サプライ種52−3の直前に受け渡されるデマンド/サプライ種を示し、順序52−4は当該単位業務内における当該デマンド/サプライ種の順番を示し、種別52−5は当該デマンド/サプライ種がデマンド種か、サプライ種かの種別を示す。図2のモデルの場合、単位業務X及び単位業務Yにはデマンド種D1、サプライ種S1の2つがあり、単位業務Zにはデマンド種D2、D3、サプライ種S2、S3の4つがあるため、それらについて図4に示されるように定義されている。
【0044】
例えばレコードR22は、単位業務Xにおいて、サプライ種S1は、デマンド種D1の次に引き渡される情報であり、その順番は2番目であることを示す。また、業務単位X及び業務単位Yのデマンド種D1について親デマンド/サプライ種52−2に「−」が設定されているのは、このデマンド種D1は最初に受け渡されるデマンド種であることを示す。なお、図4に示すように、単位業務X、Y、Zにおける情報の流れ順に定義レコードR21〜R28を並べる場合、各単位業務における情報の流れはレコードの順序で一意に決定されるので、順序52−4を省略することもできる。また、種別52−5を設けているが、デマンド/サプライ種52−3に設定されるデマンド種及びサプライ種のコード自体でデマンド種か、サプライ種かを判別できる場合には省略しても良い。
【0045】
図5は業務フローマスタ53の構成例を示す。図5に示すように、業務フローマスタ53には、単位業務間をまたがる情報の流れ毎に、飛び戻り区分53−1、親手順区分53−2、親デマンド/サプライ種53−3、手順区分53−4、デマンド/サプライ種53−5がレコードR31〜R34によって定義される。飛び戻り区分53−1には、或る単位業務から別の単位業務へ飛ぶ流れにはその旨を示すコード「G」が設定され、飛んだ先の単位業務から元の単位業務へ戻る流れにはその旨を示すコード「R」が設定される。親手順区分53−2及び親デマンド/サプライ種53−3には、情報の流れの上流側の単位業務及びデマンド/サプライ種が設定され、手順区分53−4及びデマンド/サプライ種53−5には、情報の流れの下流側の単位業務及びデマンド/サプライ種が設定される。例えば、レコードR31は、単位業務Xのデマンド種D1の次は単位業務Zのデマンド種D2に情報の流れが飛ぶことを示し、レコードR32は、単位業務Zのサプライ種S3の次は単位業務Xのサプライ種S1に情報の流れが戻ることを示す。
【0046】
単位業務間の情報の流れを定義した業務フローマスタ53は、単位業務における情報の流れを定義した業務手順マスタ52より優先される。例えば、図4のレコードR22は、単位業務Xにおけるサプライ種S1は、単位業務Xにおけるデマンド種D1を親デマンド種としているが、図5のレコードR31は、単位業務Zのデマンド種D1から単位業務Zのデマンド種D2に情報の流れが飛ぶことを定義してあるため、情報の流れは、単位業務Xのデマンド種D1→単位業務Zのデマンド種D2となる。結局、図4の業務手順マスタ52及び図5の業務フローマスタ53によって、以下のような2つの情報の流れが定義されていることになる。
(p)業務単位Xのデマンド種D1→業務単位Zのデマンド種D2→業務単位Zのサプライ種S2→業務単位Zのデマンド種D3→業務単位Zのサプライ種S3→業務単位Xのサプライ種S1
(q)業務単位Yのデマンド種D1→業務単位Zのデマンド種D2→業務単位Zのサプライ種S2→業務単位Zのデマンド種D3→業務単位Zのサプライ種S3→業務単位Yのサプライ種S1
【0047】
図6はデマンドテーブル43及びサプライテーブル44のデータ項目の一例を示す。デマンドテーブル43は、図6(a)に示すように、仕事の要求元を示すデータ項目43−1、仕事の要求先を示すデータ項目43−2、要求日時を示すデータ項目43−3、要求場所を示すデータ項目43−4、要求する仕事の対象物を示すデータ項目43−5、対象物の数を示すデータ項目43−6、仕事の期限を示すデータ項目43−7、価格を示すデータ項目43−8、要求する仕事の種類をデマンド種と手順区分で示すデータ項目43−9、自キー43−A、親キー43−B及び用途キー43−Cを有する。データ項目43−1〜43−9は、デマンド情報を構成する情報要素のうち共通情報要素を格納するデータ項目である。自キー43−Aは当該デマンド情報を一意に識別するためのキーを格納する項目である。自キー43−Aは、デマンド情報を登録する業務担当者が設定する手動設定部分キーと、サーバ1側で設定される自動設定部分キーとから構成される。手動設定部分キーは、データ項目43−1〜43−9と物理的に独立に備える以外に、データ項目43−1〜43−9の一部を手動設定部分キーとして兼用しても良い。親キー43−Bは一連の作業工程の情報の流れにおける当該デマンド情報の直前の情報(デマンド情報またはサプライ情報)に付された自キーを格納する項目である。用途キー43−Cは当該デマンド情報が属する業務プロセスの上位階層の業務プロセスにおけるデマンド情報に付与された自キーを格納する項目である。
【0048】
また、サプライテーブル44は、図6(b)に示すように、実績の報告元を示すデータ項目44−1、実績の報告先を示すデータ項目44−2、報告日時を示すデータ項目44−3、報告場所を示すデータ項目44−4、報告する対象物を示すデータ項目44−5、対象物の数を示すデータ項目44−6、計上日を示すデータ項目44−7、価格を示すデータ項目44−8、報告する実績の種類をサプライ種と手順区分で示すデータ項目44−9、自キー44−A及び親キー44−Bを、各データ項目として有する。データ項目44−1〜44−9は、サプライ情報を構成する情報要素のうち共通情報要素を格納するデータ項目である。自キー44−Aは当該サプライ情報を一意に識別するためのキーを格納する項目である。自キー44−Aは、サプライ情報を登録する業務担当者が設定する手動設定部分キーと、サーバ1側で設定される自動設定部分キーとから構成される。手動設定部分キーは、データ項目44−1〜44−9と物理的に独立に備える以外に、データ項目44−1〜44−9の一部を手動設定部分キーとして兼用しても良い。親キー44−Bは一連の作業工程の情報の流れにおける当該サプライ情報の直前の情報(デマンド情報またはサプライ情報)に付された自キーを格納する項目である。
【0049】
図7はプロパティテーブル42の論理的な構成例を示す。図7に示すようにプロパティテーブル42は、キー情報の項目42−1とプロパティの項目42−2を有する。プロパティの項目42−2には、デマンド情報またはサプライ情報の個別情報要素が格納される。キー情報の項目42−1には、その個別情報要素がどのデマンド情報、サプライ情報に属するかを示す自キーが格納される。自キーは、図6に示した自キー43−A、44−Aに相当する。
【0050】
図8はデマンド情報及びサプライ情報を共有データベース4へ登録する際の処理例を示し、図8(a)はクライアント端末3側の処理を、図8(b)はサーバ1側の処理をそれぞれ示す。
【0051】
クライアント端末3の業務担当者は、デマンド情報を共有データベース4へ登録する際、共通情報要素だけのデマンド情報で済む場合には、図6(a)に示したデータ項目43−1〜43−Cに対応するデータ項目に必要な値を設定した1つの入力用テーブルを作成し、個別情報要素の登録も行う場合には、個別情報要素の種別に応じた入力用テーブルも併せて作成する(ステップS301)。これらの入力用テーブルの作成は、ユーザ入出力部32によって表示装置6の画面に表示されるデマンド入力画面に対し、入力装置7からデータを入力していくことで行われる。その際、親キー43−Bや用途キー43−Cの内容は、後述するように共有データベース4の内容を参照することで知ることができる。サプライ情報を共有データベース4へ登録する際も同様に、共通情報要素だけのサプライ情報で済む場合には、図6(b)に示したデータ項目44−1〜44−Bに対応するデータ項目に必要な値を設定した1つの入力用テーブルを作成し、個別情報要素の登録も行う場合には、個別情報要素の種別に応じた入力用テーブルも併せて作成する(ステップS301)。このような入力用テーブルの作成も、ユーザ入出力部32によって表示装置6の画面に表示されるサプライ入力画面に対し、入力装置7からデータを入力していくことで可能である。
【0052】
次にクライアント端末3は、ネットワーク2を通じてサーバ1に接続し、デマンド登録時はデマンド登録要求と作成した入力用テーブルとをサーバ1に送信し、サプライ登録時にはサプライ登録要求と作成した入力用テーブルとをサーバ1に送信する(ステップS302)。この入力用テーブルのクライアント端末3からサーバ1への送信は、クライアント端末3から自発的に行っても良いし、デマンド登録要求、サプライ登録要求を受けたサーバ1がクライアント端末3から入力用テーブルをネットワーク2経由で取り出すことで実現しても良い。その後、クライアント端末3はサーバ1からの応答を待ち、ネットワーク2経由で応答が返されると、それを受信し、応答内容を表示装置6に表示する(ステップS303)。
【0053】
他方、サーバ1の処理部12は、クライアント端末3からデマンド登録要求またはサプライ登録要求および入力用テーブルを受信すると(ステップS101)、業務プロセス定義部5に定義された一連の作業工程間の情報の流れ通りの順序でデマンド情報またはサプライ情報の登録が行われているか否かを調べる登録可否チェックを実施する(ステップS102)。このチェックの具体的な処理は後述する。登録可能と判断した場合(ステップS103でYES)、処理部12は、登録要求されたデマンド情報またはサプライ情報を共有データベース4へ登録する(ステップS104)。
【0054】
具体的には、デマンド情報の登録要求の場合、共通情報要素が設定された入力用テーブルの自キー43−A中の自動設定部分キーをサーバ側で採番して自キー43−Aを完成させ、この入力用テーブルの内容を持つ行をデマンドテーブル43に追加する。また、個別情報要素の種別に応じた入力用テーブルが付随している場合は、その種別に応じたプロパティテーブル42に当該入力用テーブルの内容を追加する。このとき、図7に示したキー情報42−1に自キー43−Aを設定することにより、個別情報要素を共通情報要素と関連付ける。サプライ情報の登録要求の場合もほぼ同様であり、共通情報要素が設定された入力用テーブルの自キー44−A中の自動設定部分キーをサーバ側で採番して自キー44−Aを完成させて、入力用テーブルの内容を持つ行をサプライテーブル44に追加し、個別情報要素の種別に応じた入力用テーブルが付随している場合は、その種別に応じたプロパティテーブル42に当該入力用テーブルの内容を追加する。また、図7に示したキー情報42−1に自キー44−Aを設定し、個別情報要素を共通情報要素と関連付ける。
【0055】
サーバ1の処理部12は、デマンド情報またはサプライ情報の共有データベース4への登録処理を終えると、その旨を要求元のクライアント端末3へ通知する(ステップS105)。他方、登録要求されたデマンド情報またはサプライ情報が、業務プロセス定義部5に定義された一連の作業工程間の情報の流れ通りの順序でないため登録不可と判断した場合(ステップS103でNO)、サーバ1の処理部12はエラーメッセージを要求元のクライアント端末3へ通知する(ステップS106)。
【0056】
サーバ1の処理部12が行う登録可否チェック(S102)の詳細な処理の一例を図9に示す。先ず処理部12は、登録要求されたデマンド情報またはサプライ情報のデータ項目43−9または44−9に設定されたデマンド種またはサプライ種が、デマンドサプライマスタ51に定義されているか否かを調べ(ステップS111)、定義されていなければ登録不可と判断する。同時に、このステップS111において、登録要求された情報がデマンド情報であって、用途キー43−CがNULLでないとき、その用途キー43−Cに適合する自キーを持つ他のデマンド情報が既に登録されているか否かを調べ、登録されていなければ登録不可と判断する。
【0057】
登録要求されたデマンド情報またはサプライ情報のデマンド種またはサプライ種がデマンドサプライマスタ51に定義されており、且つ、登録要求された情報がデマンド情報であって、用途キー43−CがNULLでないときにその用途キー43−Cに適合する自キーを持つ他のデマンド情報が既に登録されている場合、データ項目43−Bまたは44−Bに親キーが設定されているか否かを調べ(ステップS112)、親キーの設定の有無により処理を切りわける。
【0058】
親キーが設定されていない場合、デマンド情報またはサプライ情報のデータ項目43−9または44−9に設定された手順区分及びデマンド種またはサプライ種が、業務プロセスの最初に受け渡される情報として定義されているか否かを業務手順マスタ52でチェックする(ステップS113)。このチェックにパスしなければ(ステップS114でNO)、登録不可と判断する。なお、サプライ情報は業務プロセスの最初に受け渡される情報になり得ないので、親キーの設定がないサプライ情報の登録要求は直ちに登録不可と判断して良い。ステップS113のチェックにパスした場合、重複登録が行われているか否かをチェックし(ステップS115)、重複登録の場合には登録不可と判断し、そうでない場合には登録可と判断する。ここで、重複登録とは、デマンド情報またはサプライ情報における自キー43−A、44−A中の手動設定部分キーと同じ手動設定部分キーを自キーに持つデマンド情報またはサプライ情報が、デマンドテーブル43またはサプライテーブル44に既に登録されている状態を意味する。
【0059】
他方、親キーが設定されている場合、その親キーと同じ内容を自キー43−A、44−Aに持つデマンド情報またはサプライ情報(親デマンドまたは親サプライ)をデマンドテーブル43またはサプライテーブル44から探索し(ステップS116)、そのような親デマンドまたは親サプライが存在しなければ(ステップS117でNO)、登録不可と判断する。親デマンドまたは親サプライが存在していた場合(ステップS117でYES)、この存在していた親デマンドまたは親サプライの次に受け渡される情報が今回登録要求されたデマンド情報またはサプライ情報であるか否かを、業務手順マスタ52及び業務フローマスタ53を参照してチェックする(ステップS118)。このチェックにパスしなければ(ステップS119でNO)、登録不可と判断する。チェックにパスした場合(ステップS119でYES)、ステップS115に進んで重複登録が行われているか否かをチェックし、重複登録の場合には登録不可と判断し、そうでない場合には登録可と判断する。
【0060】
図10に、デマンド情報及びサプライ情報が一連の作業工程間の情報の流れの順に関連付けて記憶されている様子を示す。ここでは、7個のデマンド情報(1)〜(7)と3個のサプライ情報(1)〜(3)が存在する。このうち、デマンド情報(1)、(2)、(5)及びサプライ情報(1)〜(3)は、業務プロセスPの或る仕事P001に関する一連の情報を示し、デマンド情報(3)、(7)は業務プロセスPの別の仕事P002に関する一連の情報を示し、デマンド情報(4)、(6)は業務プロセスPに関連する別の業務プロセスQの或る仕事Q001に関する一連の情報を示す。
【0061】
業務プロセスPの或る仕事P001に関する最初の情報であるデマンド情報(1)は、データ項目43−9に手順区分Xとデマンド種D1が設定され、自キー43−Aに「P001−01」が設定され、親キー43−Bおよび用途キー43−CはNULLになっている。自キー中の「P001」は、業務プロセスPの仕事P001を同じ業務プロセスPや他の業務プロセスQの仕事と区別するために業務担当者が付与した手動設定部分キーであり、自キー中の「01」は処理部12が付与した自動設定部分キーである。情報の流れの順でデマンド情報(1)の次の情報であるデマンド情報(2)は、データ項目43−9に手順区分Zとデマンド種D2が設定され、自キー43−Aに「P001−02」が設定され、親キー43−Bにデマンド情報(1)の自キーの値「P001−01」が設定され、用途キー43−CはNULLである。情報の流れの順でデマンド情報(2)の次の情報であるサプライ情報(1)は、データ項目44−9に手順区分Zとサプライ種S2が設定され、自キー44−Aに「P001−02−1」が設定され、親キー44−Bにデマンド情報(2)の自キーの値「P001−02」が設定されている。自キー44−Aに設定された自キー中の「P001−02」は、当該サプライ情報がデマンド情報(2)に対するサプライであることを示すために業務担当者が付与した手動設定部分キーであり、自キー中の最後尾の「1」は処理部12が付与した自動設定部分キーである。以下同様にして、業務プロセスPの仕事P001に関するデマンド情報(5)、サプライ情報(2)、サプライ情報(3)が順次に関係付けられている。
【0062】
業務プロセスPの仕事P002に関する最初の情報であるデマンド情報(3)は、データ項目43−9に手順区分Xとデマンド種D1が設定され、自キー43−Aに「P002−01」が設定され、親キー43−Bおよび用途キー43−CはNULLになっている。自キー中の「P002」は、業務プロセスPの仕事P002を同じ業務プロセスPや他の業務プロセスQの仕事と区別するために業務担当者が付与した手動設定部分キーであり、自キー中の「01」は処理部12が付与した自動設定部分キーである。情報の流れの順でデマンド情報(3)の次の情報であるデマンド情報(7)は、データ項目43−9に手順区分Zとデマンド種D2が設定され、自キー43−Aに「P002−02」が設定され、親キー43−Bにデマンド情報(3)の自キーの値「P002−01」が設定され、用途キー43−CはNULLである。業務プロセスPの仕事P002に関する情報は、現時点ではここまでが登録されている。
【0063】
業務プロセスQの仕事Q001に関する最初の情報であるデマンド情報(4)は、データ項目43−9に手順区分Yとデマンド種D1が設定され、自キー43−Aに「Q001−01」が設定され、親キー43−BにNULLが設定され、用途キー43−Cに業務プロセスPの仕事P0001に関する最初のデマンド情報(1)の自キー43−Aの値が設定されている。自キー中の「Q001」は、業務プロセスQの仕事Q001を同じ業務プロセスQや他の業務プロセスPの仕事と区別するために業務担当者が付与した手動設定部分キーであり、自キー中の「01」は処理部12が付与した自動設定部分キーである。情報の流れの順でデマンド情報(4)の次の情報であるデマンド情報(6)は、データ項目43−9に手順区分Zとデマンド種D2が設定され、自キー43−Aに「Q001−02」が設定され、親キー43−Bにデマンド情報(4)の自キーの値「Q001−01」が設定され、用途キー43−Cにデマンド情報(1)の自キー43−Aの値が設定されている。このように同じ仕事Q001に関する全てのデマンド情報の用途キー43−Cの値は同じである。業務プロセスQの仕事Q001に関する情報は、更に続くが、図10では図示を省略してある。
【0064】
図9に示した登録可否チェック処理では、デマンド情報またはサプライ情報における自キー43−A、44−A中の手動設定部分キーと同じ手動設定部分キーを自キーに持つデマンド情報またはサプライ情報は、重複登録として登録を拒否した。しかし、業務の種類やデマンド種、サプライ種によっては、或る1つの仕事を複数に分割して依頼したり、1つの依頼に対して実績を複数回に分けて報告することが行われている。従って、そのような場合には重複登録を認める必要がある。この場合、図9のステップS115は図11のステップS115−1〜S115−3のように変形される。即ち、今回登録を要求されたデマンド情報またはサプライ情報における自キー43−A、44−A中の手動設定部分キーと同じ手動設定部分キーを自キーに持つデマンド情報またはサプライ情報が、デマンドテーブル43またはサプライテーブル44に既に登録されていた場合(ステップS115−1でYES)、重複登録制御マスタをチェックして、今回登録を要求された手順区分及びデマンド種またはサプライ種が重複登録可能として定義されているか否かを調べ(ステップS115−2)、重複登録可能として定義されている場合に限り(ステップS115−3でYES)、登録可と判断する。ここで、重複登録制御マスタは、重複登録を認める手順区分とデマンド種またはサプライ種の組を定義したマスタであり、図1の業務プロセス定義部5に含められる。
【0065】
図12に、上述のような重複登録を認めた場合におけるデマンド情報及びサプライ情報の関連付けの例を示す。デマンド情報(1−1)、(1−2)は、1つのデマンド情報を2つに分けて登録したもので、デマンド情報(1−1)は、データ項目43−9に手順区分Xとデマンド種D1が設定され、自キー43−Aに「P001−01」が設定され、親キー43−Bおよび用途キー43−CはNULLになっており、デマンド情報(1−2)は、データ項目43−9に手順区分Xとデマンド種D1が設定され、自キー43−Aに「P001−02」が設定され、親キー43−Bおよび用途キー43−CはNULLになっている。つまり、自キー43−Aの手動設定部分キーは同じ「P001」であり、両者を区別するために処理部12がそれぞれ異なる自動設定部分キー「01」、「02」を付与している。デマンド情報(2−1)は、情報の流れの順でデマンド情報(1−1)の次の情報になるデマンド情報であり、データ項目43−9に手順区分Zとデマンド種D2が設定され、自キー43−Aに「P001−03」が設定され、親キー43−Bにデマンド情報(1−1)の自キーの値「P001−01」が設定され、用途キー43−CはNULLである。
【0066】
サプライ情報(1−1)、(1−2)は、デマンド情報(2−1)に対するサプライ情報を2つに分けて登録したもので、サプライ情報(1−1)は、データ項目44−9に手順区分Zとサプライ種S2が設定され、自キー44−Aに「P001−03−1」が設定され、親キー44−Bにデマンド情報(2−1)の自キーの値「P001−03」が設定されており、サプライ情報(1−2)は、データ項目44−9に手順区分Zとサプライ種S2が設定され、自キー44−Aに「P001−03−2」が設定され、親キー44−Bにデマンド情報(2−1)の自キーの値「P001−03」が設定されている。
【0067】
デマンド情報(2−2)は、情報の流れの順でデマンド情報(1−2)の次の情報になるデマンド情報であり、データ項目43−9に手順区分Zとデマンド種D2が設定され、自キー43−Aに「P001−04」が設定され、親キー43−Bにデマンド情報(1−2)の自キーの値「P001−02」が設定され、用途キー43−CはNULLである。
【0068】
デマンド情報(4−1)、(4−2)は、デマンド情報(1−1)、(1−2)が属する業務プロセスの下位階層の業務プロセスのデマンド情報を2つに分けて登録したもので、デマンド情報(4−1)は、データ項目43−9に手順区分Yとデマンド種D1が設定され、自キー43−Aに「Q001−01」が設定され、親キー43−BにNULLが設定され、用途キー43−Cにデマンド情報(1−1)の自キー43−Aの値が設定されている。また、デマンド情報(4−2)は、データ項目43−9に手順区分Yとデマンド種D1が設定され、自キー43−Aに「Q001−02」が設定され、親キー43−BはNULLであり、用途キー43−Cにはデマンド情報(1−2)の自キー43−Aの値が設定されている。
【0069】
図13は共有データベース4に登録されたデマンド情報及びサプライ情報を参照する際の処理例を示し、図13(a)はクライアント端末3側の処理を、図13(b)はサーバ1側の処理をそれぞれ示す。
【0070】
クライアント端末3の業務担当者は、共有データベース4に登録されたデマンド情報、サプライ情報を参照する場合、検索キーおよびその他の検索条件を指定してネットワーク2経由でサーバ1へ参照要求を送信する(ステップS311)。検索キーとしては、手順区分、デマンド種、サプライ種、自キー中の手動設定部分キー、用途キーの値、個別情報要素の種別、それらの組み合わせなど、予め検索キーとして定義された任意のキーを使用することができる。その後、クライアント端末3はサーバ1からの応答を待ち、サーバ1からネットワーク2経由でデマンド情報、サプライ情報が送信されてくると、それを受信し、表示装置6に表示する(ステップS312)。
【0071】
他方、サーバ1の処理部12は、ネットワーク2経由でクライアント端末3から参照要求を受信すると(ステップS121)、指定された検索キーおよびその他の検索条件で共有データベース4のデマンドテーブル43、サプライテーブル44、プロパティテーブル42を検索し、該当するデマンド情報、サプライ情報を取り出す(ステップS122)。そして、取り出したデマンド情報、サプライ情報をネットワーク2経由でクライアント端末3へ送信する(ステップS123)。
【0072】
例えば、図10に示したようなデマンド情報およびサプライ情報が登録されている状態で、検索キーとして自キー43−Aの手動設定部分キーP001を指定し、関連するデマンド情報およびサプライ情報の検索を行った場合、デマンド情報(1)、(2)、サプライ情報(1)、デマンド情報(5)、サプライ情報(2)、(3)が検索され、クライアント端末3に表示される。これにより、業務プロセスPの仕事P001の進捗状況などを把握することができる。
【0073】
また、検索キーとしてP001−01を指定して関連下位階層プロセスの検索を行えば、P001−01を自キー43−Aに持つ業務プロセスPの或る仕事P001にかかるデマンド情報(1)と、P001−01を用途キー43−Cに持つ業務プロセスQの仕事Q001にかかるデマンド情報(4)、(6)が検索され、例えば図14(a)に示すようにクライアント端末3に表示される。これにより、業務プロセスPの下位階層の業務プロセスQの仕事の進捗状況などを把握することができる。図10では、仕事P001の下位には仕事Q001しか存在しなかったが、複数存在する場合には、図14(b)に示すように関連する全ての下位階層の業務プロセスの仕事にかかるデマンド情報等が検索されて表示される。また、図10では、仕事Q001に関連する下位階層の業務プロセスは存在しなかったが、若し存在する場合には、図14(c)に示すように更に下位の業務プロセスにかかるデマンド情報等が検索されて表示される。関連する下位階層プロセスの検索とは逆に、関連する上位階層プロセスの検索も同様に可能である。
【0074】
以上の説明では、用途キー43−Cは、関連する他の仕事にかかるデマンド情報の自キー43−Aの値すべてを持つものとした。別の実施の形態として、用途キー43−Cに、自キー43−Aの値のうちの手動設定部分キーだけを設定するようにしても良い。
【0075】
【実施例】
次に本発明の実施の形態の実施例について図面を参照して詳細に説明する。本発明は、複数の作業工程から構成される業務プロセスを遂行する企業等であれば業種や業態にかかわらず広く適用可能である。以下では、一例として生産システムに本発明を適用した実施例を説明する。
【0076】
先ず、図15及び図16にそれぞれ異なる生産システムの例を示す。図15の生産システムは、計画部門を中心としたプッシュ型の生産方式である。顧客(事業部)610から受注を受けた計画部門620が、部品構成(BM)展開を行い、部材手配や生産指示を、資材部門640や製造検査部門630に対して実施する。図15において、白抜き矢印はデマンド情報、ハッチングを施した矢印はサプライ情報を表しており、実線矢印は、物流を表している。物と情報(デマンド情報とサプライ情報)が図15に示すように流れている場合、デマンド情報、サプライ情報において、各矢印の元が「誰が(Who)」、矢印の先が「誰に(Whom)」として表現され、指示対象の製品や部品は「何を(What)」、手配や出庫、組配、検査といった指示そのものは「どうする(How−Do)」として表すことができる。
【0077】
これに対して図16は、リーン生産方式を導入したプル型の業務形態を示しており、図15の生産システムとは全く逆の方式の業務形態を示す。この場合、計画部門(SBU)710は、検査部門730に対してだけ指示を出し、それ以外の工程には、後工程から順次指示が出る。すなわち、計画部門(SBU)710からの検査指示発行を受け、検査部門730から組配部門740へ組配指示、組配部門740からSMT(表面実装搭載装置)750へ指示、SMT750から資材部門720へ指示がそれぞれ発行され、計画部門(SBU)は、図15のような、資材部門との間で手配等、直接のやりとりは行わない。物と情報(デマンド情報とサプライ情報)が図16に示すように流れている場合でも、デマンド情報、サプライ情報において、各矢印の元が「誰が(Who)」、矢印の先が「誰に(Whom)」として表現され、指示対象の製品や部品は「何を(What)」、手配や出庫、組配、検査といった指示そのものは「どうする(How−Do)」として表すことができる。
【0078】
本発明は図15及び図16に示されるような任意の生産システムに対して適用可能であり、また、図15に示される生産システムを採用していた企業において、図16に示すような生産システムに変更する際にも適用可能である。
【0079】
図17は、本発明の一実施例のシステム構成図である。図17に示すように、本実施例は、U−RDB(Unified Relational Data Base;統合化関係データベース)801と呼ばれる共有データベースと、共通コンポーネント群802と、業務プロセス及び処理を定義する業務プロセス及び処理定義群803とを備えて構成されている。
【0080】
U−RDB801は、デマンド情報及びサプライ情報を格納するデマンド/サプライテーブル811、ワークフロー系および在庫系のプロパティを格納する汎用プロパティテーブル812、デマンド系およびサプライ系のプロパティを格納する個別プロパティテーブル813の3つのデータベース群からなる。図1との関係では、U−RDB801は共有データベース4に相当し、デマンド/サプライテーブル811はデマンドテーブル43及びサプライテーブル44に相当し、汎用プロパティテーブル812及び個別プロパティテーブル813はプロパティテーブル42に相当する。
【0081】
共通コンポーネント群802は、データベース(DB)検索エンジン821、構成展開エンジン822、在庫シミュレーション823、オプション処理群824、POT(Portable Terminal)/BLP(BarcodeLabel Printer)処理群825、データベース(DB)登録更新処理826の6種類のコンポーネント群からなる。POTは、物流の入出庫業務等で用いられるバーコードリーダ付きの無線端末であり、POT処理群はこの無線端末とデータ及び制御のやり取りを行うためのソフトウェア処理要素群よりなり、BLPはバーコードラベル印刷用の専用プリンタであり、BLP処理群はバーコード印刷用の専用プリンタとデータ及び制御のやり取りを行うソフトウェア処理要素群よりなる。
【0082】
また、業務プロセス及び処理定義群803は、デマンドサプライマスタ831、業務手順マスタ832、業務フローマスタ833、オプション処理マスタ834の各定義マスタからなる。図1との関係では、デマンドサプライマスタ831がデマンドサプライマスタ51に相当し、業務手順マスタ832が業務手順マスタ52に相当し、業務フローマスタ833が業務フローマスタ53に相当する。オプション処理マスタ834は、情報処理システムに必要とされるオプション処理を定義するマスタであり、具体的な処理内容はオプション処理群824に記述される。
【0083】
また、実際に業務として運用するには、外部との連携のため、対人間インタフェース(グラフィカルユーザインタフェース)804(各種業務画面等の表示を行う)と、社内外他システムインタフェース805が設けられる。図1との関係では、対人間インタフェース804は、ネットワーク2経由で接続されたクライアント端末3のユーザ入出力部32に相当する。PDM(Products Data Management)は製品情報管理(製品設計情報管理)を意味しており、社内外端末システムインタフェース805のPDMは、製品の図面/仕様書などの製品設計情報管理システムとのインタフェースである。また、CAD/CAM/CATは、CAD(Computer Aided Design;計算機支援設計)システム/CAM(Computer Aided Manufactureing;計算機設計製造)システム/CAT(ComputerAided Test;計算機支援試験)システムとのインタフェース、M/Cは工場内での自動化設備(M/C;Machine)とのインタフェースを表している。
【0084】
対人間インタフェース804は、U−RDB801の仕様を参考に、個別業務の形態に合わせ、MS−EXCEL(商標)、MS−Access(商標)等、クライアントの使い慣れたツール/言語を使い容易かつ自在に作成できる。そして、そのインタフェース部分は、画面定義やファイル転送内容の編集等であるが、元になるデータベースが共通のU−RDB801のため比較的簡単な情報処理であり、適宜変更追加することが可能であり、クライアント側(エンドユーザ側)でも容易に作成できる。このため、BPRや業務改善により、業務プロセスの変更が必要な際、このインタフェース構築/変更がネックとなって迅速な対応が損なわれることにはならない。むしろ、エンドユーザが直接、その都度対応できるので、IS(情報システム)部門に依頼し、バックログとして山積みされ、対応が遅れる弊害から免れることになる。なお、エンドユーザからU−RDB801へのアクセスは、後述するトランスファ(Transfer)サーバを介して、SQL(Structured Query Language)サーバで行われる。
【0085】
次に、本実施例の動作について、図面を参照して詳細に説明する。
【0086】
生産システムの各作業工程間で受け渡される情報は、図18に示すように、要求/指示911A、実行/実績報告911Bの2つに分類される。要求/指示911Aはデマンド情報に、実行/実績報告911Bはサプライ情報に相当する。生産システムの場合、デマンド情報には、受注、出荷指示、発注指示、設計指示、入庫指示、検査指示、組配指示、出庫指示、購入指示などの種類(デマンド種)があり、サプライ情報には、これらのデマンド種に対応して、納入、出荷実績、発注実績、設計実績、入庫実績、検査実績、組配実績、出庫実績、購入実績などの種類(デマンド種)がある。本実施例では、これら全てのデマンド種及びサプライ種の基本情報を、幾つかのWと幾つかのHとで表現してデマンド/サプライテーブル811に登録し、作業工程間で受け渡す。
【0087】
図18には、誰が(Who)、誰に(Whom)、いつ(When)、どこで(Where)、何を(What)の5つのWと、いくつ(How−Many)、いつまでに(How−Long)、いくらで(How−Much)、どうしろ(How−Do)の4つのHとで表現する場合を示す。また、この5Wと4Hで表現できない個別情報要素は、属性(補完情報)として汎用プロパティテーブル812及び個別プロパティテーブル813に登録し、作業工程間で受け渡す。補間情報として、図18には、受注仕様、図面、管理区分、検査結果、品質情報、予定情報などが示されている。なお、いつ(When)、どこに(Where)の2つのWと、いくつ(How−Many)、いつまでに(How−Long)、いくらで(How−Much)の3つのHとの、2Wと3Hは、その何れか1つ又は複数または全部をなくして、個別情報要素として管理することもできる。
【0088】
そして、本実施例においては、システムに登録できるデマンド種、サプライ種についてデマンドサプライマスタ831に定義し、また一連の作業工程間の情報の流れを業務手順マスタ832及び業務フローマスタ833に定義しておき、対人間インタフェース804からデマンド情報またはサプライ情報の登録が要求されたとき、データベース登録更新コンポーネント826で登録の可否をチェックし、情報の受け渡しが事前に定義された情報の流れの順序通りに行われるように制御している。
【0089】
図19にデマンドテーブルの内容の一例を模式的に示す。デマンドテーブルのデータ項目として、誰が、誰に、何をの3つのWと、いくつ、いつまでに、いくらで、どうする(デマンド種)の4つのHとの汎用的な名称のデータ項目がある。これらのデータ項目は、各デマンド種に応じた具体的なデータ項目名称に対応する。例えば、受注の場合、誰がは顧客に、誰には受注者に、何をは受注オーダ、客先注文番号および品名コードに、いくつは注文数に、いつまでは納期に、いくらは売価に、どうする(デマンド種)は受注に、それぞれ対応する。他のデマンド種についても図19に示すようなデータ項目がそれぞれ対応する。なお、図19では、何をのデータ項目中に自キーと親キーとを含めているが、自キーと親キーとをそれぞれ独立した項目として設けても良い。
【0090】
図20は本発明の一実施例による実際の業務遂行の様子を示す模式図であり、或る通信機製造工場の生産システムの一部を表している。以下、計画部門とその関連部門における業務事例に即して説明する。なお、業務プロセスに関するデマンド/サプライ種と、デマンド/サプライ情報の流れは、図17のデマンドサプライマスタ831、業務手順マスタ832及び業務フローマスタ833に予め定義されている。
【0091】
計画部門A1の生産手配担当者は、計画に基づき、製造部門A2への組配指示811A4と、必要資材の手配である購入要求811A1を、それぞれデマンド情報としてU−RDB801のデマンドテーブル811Aに登録する。その際、誰が(Who)は「計画部門A1」であり、誰に(Whom)はそれぞれ「製造部門A2」と「購買部門A3」になる。各部門は、自部門に出されたデマンド情報をU−RDB801のデマンドテーブル811Aから参照して業務を遂行し、業務を完了すると、各デマンド情報に対応する「実績」を、U−RDB801のサプライテーブル811Bにサプライ情報として登録することで、報告とする。この場合、購入要求デマンド811Aを受けた購買部門A3は、さらに取引先A4に対して、購入発注デマンド811A2を発行して注文する。取引先A4が納入すると、納入実績811B2をサプライ情報として計上し、同時に、購入要求811A1のサプライ情報を、購入実績811B1として、サプライテーブル811Bに登録する。最後に、計画部門A1は、この実績を受け、物流部門A5に対して、入庫指示デマンド811A3を発行する。このような流れで、仕事に必要な情報が受け渡されて業務が遂行される。
【0092】
次に、デマンド情報、サプライ情報の流れを定義する業務手順マスタ832及び業務フローマスタ833について、図20に示した業務プロセス事例を業務手順マスタ832と業務フローマスタ833に定義した状態を模式的に示す図21を参照して説明する。図21において、計画部門A1が発行するデマンド(購入要求811A1と組配指示811A4)の手順は、それぞれ、900と901で表現される。手順900では、購入要求デマンド900−1を発行し、そのサプライである購入実績サプライ900−2が計上されると、入庫指示デマンド900−3を出し、入庫完了で入庫実績サプライ900−4を計上するという手順を規定している。この手順900の定義情報が、業務手順マスタ832に登録されている。また、購入要求デマンド900−1を受けた購入部門A3の購入の手順として、手順902が定義されており、この手順902が完了すると、手順900の手順に戻っていく流れとなる。この場合の、手順900から手順902への飛び、手順902から手順900への戻りの関係を定義したものが、業務フローマスタ833である。
【0093】
次に、本発明の一実施例で用いられるサーバ環境について、図22を参照して説明する。各部署に配置された端末H2から、実際に各種のデマンド情報およびサプライ情報の入力や検索が行われるが、この処理は、端末からの処理の振り分けを行う仲介サーバとして機能するトランスファ(Transfer)サーバH1に対して、要求種別や検索キーなどを表す処理パラメータH2−1とデータH2−2を送ることで行われる。トランスファサーバH1は、端末H2から送られた処理パラメータH2−1及びデータH2−2を受け取り、処理パラメータH2−1の要求種別に対応する基幹サーバH3、H4、H5や、他のサーバを選択して、処理を実行させる。ここで、基幹サーバH3は、デマンド/サプライテーブル811を保持管理するサーバ、基幹サーバH4は、生産BM等を保持管理するサーバ、基幹サーバH5は、仕様書、図面、CADデータ等のプロパティテーブル812、813を保持管理するサーバである。
【0094】
例えば、トランスファサーバH1は、デマンド登録処理やサプライ登録処理が要求された場合には、基幹サーバH3を選択し、DB登録更新コンポーネント826(図17参照)を実行させ、デマンド情報やサプライ情報を、デマンド/サプライテーブル811(図17参照)に登録する。また、受け取った要求が、検索要求の場合、必要な基幹サーバにDB検索エンジン821を実行させることで検索を行わせる。例えば、受け取った要求が組配指示情報と組縦図面を検索する場合には、基幹サーバH3に、DB検索エンジン821を実行させるとともに、図面/仕様書が格納されている基幹サーバH5を選択し、必要な情報を取り出し、端末H2に渡す処理を行う。
【0095】
トランスファサーバH1は、他システムとの接続も管理実行する機能を持つ。事例では、表面実装搭載装置(SMT)H7への作業指示、搭載仕様/実績収集、他者システムH6への情報転送などを行っている。これらの転送情報も、デマンド/サプライの個別プロパティの一種として、個別プロパティテーブル813に登録される。また、トランスファサーバH1は、端末H2の担当者に構成展開エンジン822や在庫シミュレーション823等の機能を提供する。
【0096】
次に、図23を参照して、汎用プロパティテーブル812及び個別プロパティテーブル813について説明する。汎用プロパティテーブル812は、システムとして標準的に備わるプロパティテーブルであり、ワークフロー系プロパティテーブルと、図23には図示していないが在庫系プロパティテーブルとに大別される。ワークフロー系プロパティテーブルは、デマンドの受け渡しやデマンドに対する納期回答情報などの支援をするためのテーブルである。具体的には、デマンドを受け付けた側が指定デマンドに対する実行可否判断後に意思表示を行うためのデマンド受け付けプロパティテーブル、デマンド受けた側が日程および数量の回答(予定入力)を行うデマンド予定プロパティテーブル、サプライ入力時にデマンドのキーを取得するための伝票番号情報を管理する伝票番号制御プロパティテーブルなどがある。
【0097】
他方、個別プロパティテーブル813は、デマンド系プロパティテーブルとサプライ系プロパティテーブルとに分類される。デマンド系プロパティテーブルは、品目仕様、購買条件、トップシート、図面製造仕様、工事仕様NCデータ、試験仕様、出荷仕様などの種類があり、それぞれ、デマンドテーブルの該当するデマンド情報と関連付けられる。サプライ系プロパティテーブルは、検査結果、不具合・品質、入出庫履歴、在庫・有効、工数・労間、試験データなどの種類があり、それぞれ、サプライテーブルの該当するサプライ情報と関連付けられる。
【0098】
なお、本発明の一実施例において、社内他システムや社外他社システムにも、同様のデマンド/サプライテーブル及びプロパティテーブルを定義して、当システムと社内他システムや社外他社システムをトランスファサーバH1経由で接続し、それらのシステム間でやり取りされるデマンド情報やサプライ情報をU−RDB801に登録するようにしてもよい。これは、企業外システムとの一体化を容易にし、SCM(Supply Chain Management)の推進に有効であり、また同じ形式のデータベースを共有することで、仮想的な企業連携活動が可能になる。
【0099】
図22の事例では、基幹サーバ群H3〜H5と端末H2の仲介を行うトランスファサーバH1を用いているが、トランスファサーバH1を使用せず、端末H2と基幹サーバH3〜H5を直接に接続した環境に本発明を適用することも可能であり、小規模な業務に関しては、その環境で実現する場合もある。
【0100】
【発明の効果】
以上説明したように本発明によれば以下のような効果が得られる。
【0101】
業務プロセスの変更に対して機敏に変更可能である。その理由は、業務プロセスを構成する一連の作業工程間で受け渡される情報を、当該業務プロセスを構成する一連の作業工程間の情報の流れの順だけでなく、他の業務プロセスにかかる情報に関連付けて共有データベースに記憶できるため、業務プロセスの単位を例えば製品Aに関連するプロセス、製品Aを構成する個々の部品に関連するプロセスといった単位に分割して定義でき、文献1に記載の従来技術のように互いに関連するプロセスは1つのプロセスとして一括して定義する場合に比べて、業務プロセス変更に伴う定義情報の変更箇所が局所化され、対応が容易になるためである。また、他の業務プロセスとの関連付けを、用途キーによって行うため、互いに相手の情報のコピーを持ち回る場合に比べて、重複した情報の記憶が不要となる。
【0102】
業務プロセスの変更に対してより一層機敏に変更可能である。その理由は、業務プロセスを構成する一連の作業工程間の情報の流れを、一連の作業工程からなる単位業務における情報の流れを定義した業務手順マスタおよび単位業務間の情報の流れを定義した業務フローマスタによって定義しており、業務プロセスの変更に伴う定義情報の変更箇所が局所化されるためである。また、共有データベースが、作業工程間で受け渡されるデータの情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有しているため、共通情報要素以外の個別情報要素が新たに発生した場合、プロパティテーブルを追加するだけで対処できるからである。更に、デマンドテーブル及びサプライテーブルのデータ項目が、5W1H等のように汎用的に使用できるデータ項目となっているためである。
【0103】
共有データベースにおける無駄なデータ項目を削減することができる。その理由は、文献1に記載の従来技術のように業務プロセスを構成する作業工程に関連する全てのデータ項目の内容を掲示板データベースのテーブルに集約すると、作業工程によっては無駄なデータ項目が存在することになるが、作業工程間で受け渡されるデータの情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルでは、無駄なデータ項目がなくなるからである。
【0104】
業務の現在状況の把握や業務分析をより詳しく行うことができる。その理由は、仕事の依頼にかかるデマンド情報だけでなく、依頼された仕事に対する実績報告にかかるサプライ情報を記録して管理するためである。
【図面の簡単な説明】
【図1】本発明の一実施の形態にかかる業務処理管理システムの構成図である。
【図2】本発明の一実施の形態にかかる業務処理管理システムのより詳しい説明を行うために便宜上想定した業務プロセスのモデルを示す図である。
【図3】デマンドサプライマスタの論理的な構成例を示す図である。
【図4】業務手順マスタの論理的な構成例を示す図である。
【図5】業務フローマスタの論理的な構成例を示す図である。
【図6】デマンドテーブル及びサプライテーブルのデータ項目の一例を示す図である。
【図7】プロパティテーブルの論理的な構成例を示す図である。
【図8】デマンド情報及びサプライ情報を共有データベースへ登録する際のクライアント端末側及びサーバ側の処理例を示すフローチャートである。
【図9】サーバの処理部が行う登録可否チェック(S102)の詳細な処理の一例を示すフローチャートである。
【図10】デマンド情報及びサプライ情報が一連の作業工程間の情報の流れの順に関連付けて記憶されている様子を示す図である。
【図11】重複登録を求める場合の登録可否チェックの処理例を示すフローチャートである。
【図12】重複登録を認めた場合におけるデマンド情報及びサプライ情報の関連付けの例を示す図である。
【図13】共有データベースに登録されたデマンド情報及びサプライ情報を参照する際のクライアント端末側及びサーバ側の処理例を示すフローチャートである。
【図14】用途キーによって互いに関連付けられた複数の業務プロセスの仕事にかかるデマンド情報等を検索した際にクライアント端末に表示される内容を模式的に示す図である。
【図15】生産システムの一例を示す図である。
【図16】生産システムの他の例を示す図である。
【図17】本発明の一実施例のシステム構成図である。
【図18】生産システムの各作業工程間で受け渡される情報の説明図である。
【図19】本発明の一実施例におけるデマンドテーブルの内容の一例を模式的に示す図である。
【図20】本発明の一実施例におけるデマンド情報、サプライ情報の流れを定義する業務手順マスタ及び業務フローマスタを説明するための業務プロセス事例を示す図である。
【図21】図20に示した業務プロセス事例を業務手順マスタと業務フローマスタに定義した状態を模式的に示す図である。
【図22】本発明の一実施例で用いられるサーバ環境の構成図である。
【図23】本発明の一実施例で用いられる汎用プロパティテーブル及び個別プロパティテーブルの説明図である。
【符号の説明】
1…サーバ
2…ネットワーク
3…クライアント端末
4…共有データベース
5…業務プロセス定義部
6…表示装置
7…入力装置
Claims (16)
- 業務プロセスを構成する複数の作業工程間で受け渡される情報及び情報の流れを管理する業務処理管理システムであって、
一連の作業工程からなる単位業務における作業工程間で受け渡す個々の情報毎に、その情報の種別を示すデマンド/サプライ種と業務単位を示す手順区分とその情報の直前に受け渡される情報の種別を示す親デマンド/サプライ種とを定義することにより、各単位業務における情報の流れを定義した業務手順マスタ、および、単位業務間をまたがる情報の流れ毎に、情報の流れの上流側の単位業務と情報の種別を示す親手順区分と親デマンド/サプライ種、情報の流れの下流側の単位業務と情報の種別を示す手順区分とデマンド/サプライ種を定義することにより、単位業務間の情報の流れを定義した業務フローマスタを記憶し、前記業務手順マスタと前記業務フローマスタとによって、業務プロセスを構成する一連の作業工程間の情報の流れを定義する業務プロセス定義部と、
作業工程間で受け渡される情報であって、自情報を一意に識別するための自キーと、一連の作業工程の情報の流れにおける自情報の直前の情報を識別するための親キーと、関連する他の業務プロセスの情報の自キーの値を持つ用途キーとを持つ情報を記憶する共有データベースと、
クライアント端末から前記共有データベースに対する仕事に必要な情報の入出力を制御するサーバであって、前記クライアント端末から登録を要求された情報を受信し、受信した情報に親キーが設定されているかどうかを判定し、親キーが設定されていない場合には、受信した情報に含まれる手順区分およびデマンド/サプライ種で特定される情報が業務プロセスの最初に受け渡される情報として前記業務手順マスタに定義されていることを条件に今回登録要求された情報の登録を行い、親キーが設定されている場合には、該設定されている親キーと同じ内容を自キーに持つ情報を前記共有データベースから検索し、該検索に成功し且つ該検索した情報の次に受け渡される情報が今回登録要求された情報に含まれる手順区分およびデマンド/サプライ種で特定される情報であることが前記業務手順マスタおよび前記業務フローマスタを参照して確かめられたことを条件に今回登録要求された情報の登録を行うことにより、前記業務プロセス定義部に定義された業務プロセスを構成する一連の作業工程間の情報の流れ通りの順序で情報が入力されるように制御し、且つ、前記クライアント端末から受信した検索キーを自キーに持つ情報と前記検索キーを用途キーに持つ情報とを前記共有データベースから検索して、検索結果を前記クライアント端末へ送信するサーバとを備えたことを特徴とする業務処理管理システム。 - 前記共有データベースは、作業工程間で受け渡される情報の情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有する請求項1記載の業務処理管理システム。
- 業務プロセスを構成する複数の作業工程間で受け渡される情報は、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報とを含み、前記共通テーブルは、前記デマンド情報を格納するデマンドテーブルと、前記サプライ情報を格納するサプライテーブルとで構成される請求項2記載の業務処理管理システム。
- 前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、少なくとも、誰が(Who)に相当する情報要素を格納するデータ項目と、誰に(Whom)に相当する情報要素を格納するデータ項目と、何を(What)に相当する情報要素を格納するデータ項目と、どうする(How−Do)に相当する情報要素を格納するデータ項目とを備える請求項3記載の業務処理管理システム。
- 前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、更に、いつ(When)に相当する情報要素を格納するデータ項目、どこに(Where)に相当する情報要素を格納するデータ項目、いくつ(How−Many)に相当する情報要素を格納するデータ項目、いつまでに(How−Long)に相当する情報要素を格納するデータ項目、いくらで(How−Much)に相当する情報要素を格納するデータ項目のうち、少なくとも1つのデータ項目を備える請求項4記載の業務処理管理システム。
- 一連の作業工程からなる単位業務における作業工程間で受け渡す個々の情報毎に、その情報の種別を示すデマンド/サプライ種と業務単位を示す手順区分とその情報の直前に受け渡される情報の種別を示す親デマンド/サプライ種とを定義することにより、各単位業務における情報の流れを定義した業務手順マスタ、および、単位業務間をまたがる情報の流れ毎に、情報の流れの上流側の単位業務と情報の種別を示す親手順区分と親デマンド/サプライ種、情報の流れの下流側の単位業務と情報の種別を示す手順区分とデマンド/サプライ種を定義することにより、単位業務間の情報の流れを定義した業務フローマスタを記憶し、前記業務手順マスタと前記業務フローマスタとによって、業務プロセスを構成する一連の作業工程間の情報の流れを定義する業務プロセス定義部と、
作業工程間で受け渡される情報であって、自情報を一意に識別するための自キーと、一連の作業工程の情報の流れにおける自情報の直前の情報を識別するための親キーと、関連する他の業務プロセスの情報の自キーの値を持つ用途キーとを持つ情報を記憶する共有データベースと、
クライアント端末から前記共有データベースに対する仕事に必要な情報の入出力を制御するサーバと、
前記サーバにネットワーク経由で接続されたクライアント端末とから構成され、
業務プロセスを構成する複数の作業工程間で受け渡される情報及び情報の流れを管理する情報処理システムにおける業務処理管理方法であって、
前記サーバにおいて、前記クライアント端末から登録を要求された情報を受信し、受信した情報に親キーが設定されているかどうかを判定し、親キーが設定されていない場合には、受信した情報に含まれる手順区分およびデマンド/サプライ種で特定される情報が業務プロセスの最初に受け渡される情報として前記業務手順マスタに定義されていることを条件に今回登録要求された情報の登録を行い、親キーが設定されている場合には、該設定されている親キーと同じ内容を自キーに持つ情報を前記共有データベースから検索し、該検索に成功し且つ該検索した情報の次に受け渡される情報が今回登録要求された情報に含まれる手順区分およびデマンド/サプライ種で特定される情報であることが前記業務手順マスタおよび前記業務フローマスタを参照して確かめられたことを条件に今回登録要求された情報の登録を行うことにより、前記業務プロセス定義部に定義された業務プロセスを構成する一連の作業工程間の情報の流れ通りの順序で情報が入力されるように制御するステップと、
前記クライアント端末から受信した検索キーを自キーに持つ情報と前記検索キーを用途キーに持つ情報とを前記共有データベースから検索して、検索結果を前記クライアント端末へ送信するステップとを含む業務処理管理方法。 - 前記共有データベースは、作業工程間で受け渡される情報の情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有する請求項6記載の業務処理管理方法。
- 業務プロセスを構成する複数の作業工程間で受け渡される情報は、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報とを含み、前記共通テーブルは、前記デマンド情報を格納するデマンドテーブルと、前記サプライ情報を格納するサプライテーブルとで構成される請求項7記載の業務処理管理方法。
- 前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、少なくとも、誰が(Who)に相当する情報要素を格納するデータ項目と、誰に(Whom)に相当する情報要素を格納するデータ項目と、何を(What)に相当する情報要素を格納するデータ項目と、どうする(How−Do)に相当する情報要素を格納するデータ項目とを備える請求項8記載の業務処理管理方法。
- 前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、更に、いつ(When)に相当する情報要素を格納するデータ項目、どこに(Where)に相当する情報要素を格納するデータ項目、いくつ(How−Many)に相当する情報要素を格納するデータ項目、いつまでに(How−Long)に相当する情報要素を格納するデータ項目、いくらで(How−Much)に相当する情報要素を格納するデータ項目のうち、少なくとも1つのデータ項目を備える請求項9記載の業務処理管理方法。
- 一連の作業工程からなる単位業務における作業工程間で受け渡す個々の情報毎に、その情報の種別を示すデマンド/サプライ種と業務単位を示す手順区分とその情報の直前に受け渡される情報の種別を示す親デマンド/サプライ種とを定義することにより、各単位業務における情報の流れを定義した業務手順マスタ、および、単位業務間をまたがる情報の流れ毎に、情報の流れの上流側の単位業務と情報の種別を示す親手順区分と親デマンド/サプライ種、情報の流れの下流側の単位業務と情報の種別を示す手順区分とデマンド/サプライ種を定義することにより、単位業務間の情報の流れを定義した業務フローマスタを記憶し、前記業務手順マスタと前記業務フローマスタとによって、業務プロセスを構成する一連の作業工程間の情報の流れを定義する業務プロセス定義部と、
作業工程間で受け渡される情報であって、自情報を一意に識別するための自キーと、一連の作業工程の情報の流れにおける自情報の直前の情報を識別するための親キーと、関連する他の業務プロセスの情報の自キーの値を持つ用途キーとを持つ情報を記憶する共有データベースとに接続されると共に、ネットワーク経由でクライアント端末に接続され、クライアント端末から前記共有データベースに対する仕事に必要な情報の入出力を制御するサーバ装置であって、
前記クライアント端末から登録を要求された情報を受信し、受信した情報に親キーが設定されているかどうかを判定し、親キーが設定されていない場合には、受信した情報に含まれる手順区分およびデマンド/サプライ種で特定される情報が業務プロセスの最初に受け渡される情報として前記業務手順マスタに定義されていることを条件に今回登録要求された情報の登録を行い、親キーが設定されている場合には、該設定されている親キーと同じ内容を自キーに持つ情報を前記共有データベースから検索し、該検索に成功し且つ該検索した情報の次に受け渡される情報が今回登録要求された情報に含まれる手順区分およびデマンド/サプライ種で特定される情報であることが前記業務手順マスタおよび前記業務フローマスタを参照して確かめられたことを条件に今回登録要求された情報の登録を行うことにより、前記業務プロセス定義部に定義された業務プロセスを構成する一連の作業工程間の情報の流れ通りの順序で情報が入力されるように制御する手段と、
前記クライアント端末から受信した検索キーを自キーに持つ情報と前記検索キーを用途キーに持つ情報とを前記共有データベースから検索して、検索結果を前記クライアント端末へ送信する手段とを含むサーバ装置。 - 前記共有データベースは、作業工程間で受け渡される情報の情報要素のうち全ての作業工程で共通な共通情報要素を記憶する共通テーブルと、それ以外の個別情報要素を記憶するプロパティテーブルとを有する請求項11記載のサーバ装置。
- 業務プロセスを構成する複数の作業工程間で受け渡される情報は、仕事の依頼にかかるデマンド情報とその依頼された仕事に対する実績報告にかかるサプライ情報とを含み、前記共通テーブルは、前記デマンド情報を格納するデマンドテーブルと、前記サプライ情報を格納するサプライテーブルとで構成される請求項12記載のサーバ装置。
- 前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、少なくとも、誰が(Who)に相当する情報要素を格納するデータ項目と、誰に(Whom)に相当する情報要素を格納するデータ項目と、何を(What)に相当する情報要素を格納するデータ項目と、どうする(How−Do)に相当する情報要素を格納するデータ項目とを備える請求項13記載のサーバ装置。
- 前記デマンドテーブル及び前記サプライテーブルは、前記デマンド情報及び前記サプライ情報を格納するデータ項目として、更に、いつ(When)に相当する情報要素を格納するデータ項目、どこに(Where)に相当する情報要素を格納するデータ項目、いくつ(How−Many)に相当する情報要素を格納するデータ項目、いつまでに(How−Long)に相当する情報要素を格納するデータ項目、いくらで(How−Much)に相当する情報要素を格納するデータ項目のうち、少なくとも1つのデータ項目を備える請求項14記載のサーバ装置。
- 一連の作業工程からなる単位業務における作業工程間で受け渡す個々の情報毎に、その情報の種別を示すデマンド/サプライ種と業務単位を示す手順区分とその情報の直前に受け渡される情報の種別を示す親デマンド/サプライ種とを定義することにより、各単位業務における情報の流れを定義した業務手順マスタ、および、単位業務間をまたがる情報の流れ毎に、情報の流れの上流側の単位業務と情報の種別を示す親手順区分と親デマンド/サプライ種、情報の流れの下流側の単位業務と情報の種別を示す手順区分とデマンド/サプライ種を定義することにより、単位業務間の情報の流れを定義した業務フローマスタを記憶し、前記業務手順マスタと前記業務フローマスタとによって、業務プロセスを構成する一連の作業工程間の情報の流れを定義する業務プロセス定義部と、
作業工程間で受け渡される情報であって、自情報を一意に識別するための自キーと、一連の作業工程の情報の流れにおける自情報の直前の情報を識別するための親キーと、関連する他の業務プロセスの情報の自キーの値を持つ用途キーとを持つ情報を記憶する共有データベースとに接続されると共に、ネットワーク経由でクライアント端末に接続され、クライアント端末から前記共有データベースに対する仕事に必要な情報の入出力を制御するサーバ装置を構成するコンピュータを、
前記クライアント端末から登録を要求された情報を受信し、受信した情報に親キーが設定されているかどうかを判定し、親キーが設定されていない場合には、受信した情報に含まれる手順区分およびデマンド/サプライ種で特定される情報が業務プロセスの最初に受け渡される情報として前記業務手順マスタに定義されていることを条件に今回登録要求された情報の登録を行い、親キーが設定されている場合には、該設定されている親キーと同じ内容を自キーに持つ情報を前記共有データベースから検索し、該検索に成功し且つ該検索した情報の次に受け渡される情報が今回登録要求された情報に含まれる手順区分およびデマンド/サプライ種で特定される情報であることが前記業務手順マスタおよび前記業務フローマスタを参照して確かめられたことを条件に今回登録要求された情報の登録を行うことにより、前記業務プロセス定義部に定義された業務プロセスを構成する一連の作業工程間の情報の流れ通りの順序で情報が入力されるように制御する手段と、
前記クライアント端末から受信した検索キーを自キーに持つ情報と前記検索キーを用途キーに持つ情報とを前記共有データベースから検索して、検索結果を前記クライアント端末へ送信する手段として機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001399528A JP4002436B2 (ja) | 2001-12-28 | 2001-12-28 | 業務処理管理システム及びその方法、サーバ装置並びにプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001399528A JP4002436B2 (ja) | 2001-12-28 | 2001-12-28 | 業務処理管理システム及びその方法、サーバ装置並びにプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2003196441A JP2003196441A (ja) | 2003-07-11 |
JP4002436B2 true JP4002436B2 (ja) | 2007-10-31 |
Family
ID=27604514
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001399528A Expired - Fee Related JP4002436B2 (ja) | 2001-12-28 | 2001-12-28 | 業務処理管理システム及びその方法、サーバ装置並びにプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4002436B2 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4923638B2 (ja) * | 2006-03-09 | 2012-04-25 | 富士電機株式会社 | 知見・ノウハウの体系化データベース構築装置および方法 |
JP2007241886A (ja) * | 2006-03-10 | 2007-09-20 | Fuji Electric Systems Co Ltd | 製品の表現方法 |
JP4984580B2 (ja) * | 2006-03-10 | 2012-07-25 | 富士電機株式会社 | 不具合対策支援装置 |
CN105988431B (zh) * | 2015-01-30 | 2018-06-01 | 中芯国际集成电路制造(上海)有限公司 | 管理信息系统及其产品流程的配置数据更新方法与装置 |
-
2001
- 2001-12-28 JP JP2001399528A patent/JP4002436B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2003196441A (ja) | 2003-07-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10042904B2 (en) | System of centrally managing core reference data associated with an enterprise | |
US8239426B2 (en) | Data management system providing a data thesaurus for mapping between multiple data schemas or between multiple domains within a data schema | |
JP5064211B2 (ja) | 電子カタログのサプライヤ・ポータルのためのシステムおよび方法 | |
US7788119B2 (en) | System providing for inventory optimization in association with a centrally managed master repository for core reference data associated with an enterprise | |
JP4002436B2 (ja) | 業務処理管理システム及びその方法、サーバ装置並びにプログラム | |
JP3970607B2 (ja) | 業務処理管理システム及びその方法、サーバ装置並びにプログラム | |
CN112288150A (zh) | 一种船舶工业管件加工管控集成系统 | |
Joia | Large-scale reengineering in project documentation and workflow at engineering consultancy companies | |
KR100423865B1 (ko) | 민첩 정보 시스템 및 관리 방법 | |
JP2004139472A (ja) | 作業計画立案システム、作業計画立案方法及びプログラム並びに媒体 | |
JP2002175394A (ja) | 業務処理管理システム及びその方法、サーバ装置並びにプログラム | |
US20020169646A1 (en) | Planning and administrating a manufacturing plant | |
JP2001306718A (ja) | コンピュータ及び通信技術を使った情報関連事業を提供する事業システム | |
KR102600679B1 (ko) | 섬유패션산업을 위한 클라우드 협업 시스템 | |
TW200832244A (en) | System and method for flexibly processing data on production line | |
Klenz et al. | The Quality Data Warehouse: Solving Problems for the Enterprise | |
Waiyanet et al. | Implementation of validate invoice and packing list document process by Microsoft Access a case study of ABC logistics company | |
JP2001134668A (ja) | ワークフロー管理方式を用いた進捗管理システム | |
Klenz | The quality data warehouse: Serving the analytical needs of the manufacturing enterprise | |
JP2002197327A (ja) | 個別注文管理システム | |
JP2002189842A (ja) | ワークフロー管理制御システムとその方法並びにワークフロー管理制御プログラムを記録した記録媒体 | |
Rijks et al. | Applying Business Process Redesign Heuristics in an Artifact Centric Process Modeling Approach | |
JP2003187114A (ja) | サプライチェーン管理システム | |
JPWO2013114447A1 (ja) | 携帯端末管理サーバ、および携帯端末管理プログラム | |
JPWO2013114449A1 (ja) | 携帯端末管理サーバ、および携帯端末管理プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041115 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070219 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070227 |
|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20070326 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070418 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070807 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070817 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100824 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4002436 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110824 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110824 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120824 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130824 Year of fee payment: 6 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130824 Year of fee payment: 6 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
LAPS | Cancellation because of no payment of annual fees |