WO2012086097A1 - データベース、データ管理サーバ、およびデータ管理プログラム - Google Patents

データベース、データ管理サーバ、およびデータ管理プログラム Download PDF

Info

Publication number
WO2012086097A1
WO2012086097A1 PCT/JP2011/002352 JP2011002352W WO2012086097A1 WO 2012086097 A1 WO2012086097 A1 WO 2012086097A1 JP 2011002352 W JP2011002352 W JP 2011002352W WO 2012086097 A1 WO2012086097 A1 WO 2012086097A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
process flow
status
update condition
update
Prior art date
Application number
PCT/JP2011/002352
Other languages
English (en)
French (fr)
Inventor
秋田敏文
Original Assignee
株式会社アイ・ピー・エス
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 株式会社アイ・ピー・エス filed Critical 株式会社アイ・ピー・エス
Priority to EP11850457.0A priority Critical patent/EP2527994A4/en
Priority to JP2012529059A priority patent/JP5386639B2/ja
Priority to CN2011800154165A priority patent/CN102812462A/zh
Priority to US13/574,384 priority patent/US8812471B2/en
Publication of WO2012086097A1 publication Critical patent/WO2012086097A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present invention relates to a database that can be used in an ERP system, a data management server including the database, and a data management program installed in the data management server.
  • ERP Enterprise Resource Planning
  • Such a system includes, for example, an integrated business system that manages information on management resources and communicates information in a predetermined first data format.
  • a data conversion device connected to a plurality of information devices that communicate information in a second data format different from the data format, and accepts input of information in the first data format output from the integrated business system.
  • the “input process” means a process of inputting various data acquired (or determined) by an ERP system administrator or the like in each business process to each table.
  • FIG. 12 is an explanatory diagram for explaining an example of a table configuration in a conventional ERP system.
  • a business flow composed of a plurality of business processes indicates “inventory sales”
  • the table for storing the data related to the process flow of “inventory sales” is, for example, as shown in FIG. 12 (A) to FIG. 12 (E), for each input process, an order receipt table, a shipping instruction table, and a delivery table. , An acceptance table, and a sales table.
  • the table to be updated is different for each input process. For this reason, the correspondence between a plurality of business processes belonging to the same process flow is an identifier (in FIG. 12, the order number and order details in the shipping instruction table, and the delivery table in the data (process data) relating to each business process). The shipping instruction number and the shipping instruction details, etc.) are given.
  • the shipping instruction for specifying the process data as the process data related to the business process “shipment instruction” The order number “A00001” and the order received together with the number, the shipping instruction detail number, the type indicating the type of the business process, and the data indicating the contents of the business process (for example, the order recipient, quantity, amount, shipping instruction date, shipping text, etc.) Register the item number “0010” in the shipping instruction table.
  • the same data for example, orders, quantity, amount, etc.
  • An object of the present invention is to solve the above-described problems and reduce the processing load required for data update and search in an ERP system.
  • the database of the present invention includes a process flow table in which process flow data including various data related to a process flow including a plurality of business processes is registered, and an update condition table in which update condition data indicating an update condition of the process flow data is registered.
  • the process flow data is data including status data, common data, and process specific data
  • the status data is data indicating a progress status of each of a plurality of business processes included in the process flow.
  • the common data is data common to business processes included in the same process flow
  • the process specific data is data specific to each business process included in the same process flow
  • the status Data is process specific Updated in response to the over data has been updated, the update condition data, characterized in that it is a data indicating the state of the status data.
  • the above configuration makes it possible to reduce the processing load required for data update and search in the ERP system.
  • a process flow data management server that manages process flow data generated for each process flow
  • the process flow data management server receives a part or all of the process flow data in response to a request from a client terminal. You may be set as the structure containing the process flow data provision means provided to a client terminal.
  • the process flow data management server receives process data received by the process data receiving means based on the update condition data, and process data receiving means for receiving input of process data that is data relating to each of the plurality of business processes.
  • Registration determination means for determining whether to register as part of the process flow data, and the process flow data registered in the process flow table in response to the registration determination means determining that the process data is to be registered
  • the process flow data updating means for updating the process flow data may be included.
  • the process flow data management server includes a non-satisfied update condition identifying unit that identifies a non-satisfied update condition that is an unsatisfied update condition in response to a determination that the process data is not registered by the registration determination unit.
  • a notification unit for notifying the client terminal of the unsatisfied update condition specified by the unsatisfied update condition specifying unit, and a satisfaction determination for determining whether the update condition specified as the unsatisfied update condition is satisfied at a predetermined timing
  • the process flow data update means outputs the process data corresponding to the update condition in response to the fact that the update condition specified as the unsatisfied update condition is satisfied by the satisfaction determination means. It may be configured to be registered in the process flow table.
  • the data management server of the present invention is a data management server that provides various data to a client terminal, and includes process flow data including various data related to a process flow including a plurality of business processes, and the process flow data
  • process flow data storage means for storing update condition data indicating an update condition
  • process flow data update means for updating the process flow data according to the progress of the process flow
  • Process flow data providing means for providing a part or all of the process flow data to the client terminal
  • the process flow data is data including status data, common data, and process specific data
  • the status data It is data indicating the progress of each of a plurality of business processes included in the process flow
  • the common data is data common to business processes included in the same process flow
  • the process specific data is the same process
  • the update condition data is data indicating a status of the status data
  • the process flow data update unit is configured to process the process flow data based on the update condition data. It is characterized by updating.
  • the data management program of the present invention is a data management program for controlling the operation of the data management server so as to provide various data to the client terminal
  • the data management server includes a plurality of business processes.
  • the process flow data stored in the process flow data storage means for storing process flow data including various data related to the process flow and update condition data indicating an update condition of the process flow data is updated according to the progress of the process flow.
  • Process flow data update processing and in response to a request from the client terminal, process flow data provision processing for providing a part or all of the process flow data to the client terminal is executed.
  • Status data Common data and process specific data
  • the status data is data indicating the progress of each of the plurality of business processes included in the process flow
  • the common data is in the same process flow.
  • the process-specific data is data common to the business processes included, the process-specific data is data specific to each business process included in the same process flow, and the update condition data is data indicating the status data status.
  • the process flow data update process a process for updating the process flow data based on the update condition data is executed.
  • FIG. 1 is a block diagram showing a configuration example of an integrated core business system 500 according to an embodiment of the present invention.
  • the integrated core business system 500 includes a core business server 200, a data warehouse server (DWH server) 300, a client 10, and a client 20.
  • DWH server data warehouse server
  • Each element constituting the integrated core business system 500 is connected by a communication network.
  • the core business server 200 and the DWH server 300 are connected by a dedicated line 51.
  • the client 10 is connected to the DWH server 300 via a LAN (Local Area Network) 52.
  • the client 20 is connected to the DWH server 300 via the Internet 53.
  • the core business server 200 is a server managed by an administrator of the integrated core business system 500, for example, and has various functions for managing process data that is data indicating information in various business processes such as form information related to various businesses. Have.
  • the core business server 200 in this example is configured by a general information processing apparatus including an OS (Operating System) and a relational database (relational DB).
  • OS Operating System
  • relational database relational database
  • a book is a field in which items relating to cash and goods are entered
  • a slip is data that is the basis for creating a book and is evidence of business transactions.
  • the core business server 200 may handle, for example, process data indicating only slip information used for creating various slips.
  • the core business server 200 in this example includes a business application program DB 210, a process flow DB 220, and various types of data necessary for realizing a function as a general core business server (for example, And other DBs 230 that store data used by various programs stored in the business application program DB 210.
  • the other DB 230 is a part not particularly related to the present invention, and a detailed description thereof will be omitted.
  • the business application program DB 210 is a storage medium that stores programs used for various businesses. Programs stored in the business application program DB 210 include a sales business management program, a purchasing business management program, a production management program, a financial accounting management program, and a management accounting management program.
  • the process flow DB 220 is a storage medium that stores process flow data including various process data (or form data) collected and organized by various information processing using various programs stored in the business application program DB 210. is there.
  • process flow data including various data related to a process flow including a plurality of business processes is stored in the process flow table PT in the process flow DB 220.
  • the core business server 200 centrally manages process flow data generated for each process flow using one process flow table PT.
  • the core business server 200 manages the process flow data in a plurality of tables, for example, for each type to be described later, or for each piece of common data to be described later (for example, an order receiving party). It is good also as a structure.
  • FIG. 2 is an explanatory diagram illustrating an example of a storage state of process flow data in the process flow DB 220.
  • the process flow data in this example includes a main key part, a reference key part, a type part, a status part, a common data part, and a process specific data part.
  • Each item corresponding to each part of the process flow data indicates the type of process data constituting the process flow data.
  • data relating to each business process constituting the process flow is allocated and stored in each part constituting the process flow data.
  • process data related to one process flow (for example, a series of process flows from order receipt to delivery from a certain company) is stored in the same entry (that is, the same row in the process table PT) in the process flow table PT.
  • process data related to one process flow (for example, a series of process flows from order receipt to delivery from a certain company) is stored in the same entry (that is, the same row in the process table PT) in the process flow table PT.
  • the “primary key part” is a part in which primary key data, which is data for uniquely identifying the process flow data, is stored in the process flow data.
  • the main key part is composed of a process flow number and a process flow detail number. That is, in this example, a combination of a process flow number and a process flow detail number becomes an identifier (ID) of each process flow data.
  • the main key part is updated when the process flow data is registered for the first time.
  • “when first registering process flow data” means that when an entry (data row) is added to the process flow data, for example, process data belonging to a certain process flow and corresponding other processes It shall mean the time when unregistered process data is registered.
  • the “update” here includes addition of data.
  • the “process flow number” is an identifier for specifying one process flow data (that is, one column in the process flow table PT shown in FIG. 2).
  • the process flow number is assigned to each process data having the same predetermined item.
  • the same number is assigned to the process flow number of the process flow number that has the same type and the order-receiving party in the process flow data.
  • the “process flow detail number” is an identifier for identifying specific process flow data from among the process flow data assigned with the same process flow number. That is, for example, the process flow table PT shown in FIG. 2 indicates that the business process “order received” in the process flow type “inventory sales” has received orders for the amounts “1200” and “2600” from the order recipient “T001”.
  • the process flow data including the process data to be shown can be uniquely identified by the combination of the process flow number “000001” and the process flow detail number “0010” or “0020”, respectively.
  • the “reference key part” is data for specifying other process flow data (or other process data) related to the process flow, such as the original transaction for sales returns, among the process flow data. This is the part where key data is stored.
  • the reference key part is composed of a reference number and a reference specification number. The reference key part is updated when the process flow data is registered for the first time.
  • the process number and process flow detail number of other process flows related to the process flow are stored in the reference number and the reference detail number, respectively.
  • the reference key portion contains data indicating the same value as the primary key portion of the same entry (that is, the reference number is a process)
  • a flow number is stored, and a process flow item number is stored in the reference item number.
  • the reference key part indicates other process data related to the process flow, the reference key part is further provided with data for specifying the type of the process data.
  • the “type part” is a part in which type data that is a type of process flow, such as inventory sales and sample shipment, is stored in the process flow data.
  • the type part is updated when the process flow data is registered for the first time.
  • the type of process flow is not limited to inventory sales or sample shipment.
  • the “status part” stores status data that is data indicating the progress of the process flow (that is, data indicating the progress of each of a plurality of business processes included in the process flow) among the process flow data.
  • the status data indicates the progress of each business process by setting “0” for the unfinished business process and “1” for the completed business process for the business process required by the process flow. Show. That is, for example, as shown in FIG. 2, the process flow of “inventory sales”, and the business processes included in the process flow are “order receipt”, “shipment”, “issue”, “issue inspection”, and “sales”. In this case, it is assumed that process specific data (for example, order date) related to the business process “order received” is registered. In this case, in the status data, the portion corresponding to “sales” is “1”, and the other portions remain in the initial state (ie, the state in which “0” is set).
  • the status part in this example is updated for each business process.
  • the status part is updated when process-specific data to be described later is input, specifically, when it is determined that each business process is completed because a predetermined status change condition is satisfied.
  • the status change condition is not particularly limited, in this example, “all process specific data corresponding to one business process is input” is stored in the predetermined storage area of the core business server 200 as the status change condition. It is assumed that
  • a part of the items (column items) constituting the table stores unnecessary process data in a specific process flow.
  • a part for storing unnecessary process data is empty data, and “0” is stored in status data corresponding to the empty data.
  • the “common data part” is data that does not depend on the business process such as the order receiving party and the shipping destination among the process flow data (that is, common data between business processes included in the same process flow). This is the part where data is stored. The common data part is updated when the process flow data is registered for the first time.
  • process specific data part is a text that indicates precautions such as the order date and data registered in each business process in the process flow data (for example, “delivery deadline” and “breaker”) Data), etc., is a part in which process-specific data that is data unique to each business process included in the same process flow is stored.
  • the process specific data part is updated for each business process. Therefore, in this example, it can be said that the process flow data based on the business process is “process-specific data” and the data not based on the business process is “common data”.
  • order received means a state in which an order is received from a customer and a contract with the customer is concluded.
  • shipment instruction means a state in which an instruction to ship a product is given to a warehouse company or a logistics person.
  • shipment means a state in which goods are shipped from the warehouse and movement is started.
  • Inspection means a state in which the inspection of the customer is completed and the ownership of the product is transferred to the customer.
  • the process flow DB 220 includes an update condition table UT in which update condition data indicating update conditions of the process flow data (or process flow table PT) is registered.
  • FIG. 3 is an explanatory diagram illustrating an example of a storage state of update condition data in the process flow DB 220.
  • the update condition data in this example includes a business process name, a process flow type, and a process flow data update condition.
  • the “process flow data update condition” indicates the process data registration condition corresponding to the process flow type.
  • the process flow data update condition is defined as the type of process data that the process flow data should have as a prerequisite when process data related to a certain business process is added to the process flow data (that is, in the process flow). Indicates the type of business process that should be completed). That is, when the update condition table UT is as shown in FIG.
  • update condition table UT may be configured to be created by the administrator of the integrated core business system 500, or may be configured to be created by the users of the clients 10 and 20.
  • the core business server 200 receives various data stored in the process flow DB 220 and the other DB 230 in accordance with a predetermined extraction condition as a CSV. (Comma Separated Values) The function of converting to the format and transmitting to the DWH server 300 is provided. In this example, the core business server 200 transfers a data file in CSV format by FTP (File Transfer Protocol) to the DWH server 300.
  • FTP File Transfer Protocol
  • the DWH server 300 is a server managed by a system administrator of this system, for example, and has various functions for realizing a data warehouse.
  • the “data warehouse” refers to a system that analyzes the relationship between items from business data such as form data accumulated in time series (in this example, process flow data).
  • the DWH server 300 has a function of registering various data in a predetermined storage area by converting a CSV file transferred from the core business server 200 into a predetermined data format.
  • the DWH server 300 may be configured to extract data corresponding to each storage area from the CSV format state without converting the data format.
  • Clients 10 and 20 are information processing apparatuses (client terminals) including a CPU (Central Processing Unit), ROM, RAM, and a display unit.
  • clients 10 and 20 have various applications such as a Web browser and spreadsheet software that can be used to handle form data.
  • the clients 10 and 20 for example, in response to an operation input by the user, a query (search item, search item, data flow in this example) for obtaining necessary form data (process flow data) from the DWH server 300.
  • search item search item, search item, data flow in this example
  • necessary form data process flow data
  • the client 10 has a function of communicating with the DWH server 300 via the LAN and outputting the data acquired from the DWH server 300 to the display unit using predetermined spreadsheet software.
  • the client 20 has a function of communicating with the DWH server 300 via the Internet and outputting data acquired from the DWH server 300 to a display unit using a Web browser.
  • the clients 10 and 20 have a function of outputting a form having a predetermined form to a display unit included in the client 10 or 20 based on the process flow data stored in the process flow DB 220 of the core business server 200. .
  • the configuration of the integrated core business system 500 is not limited to this.
  • the clients 10 and 20 and the core business server 200 may directly transmit and receive data without using the DWH server 300.
  • the clients 10 and 20 may be configured to be directly accessible to the process flow DB 220B.
  • FIG. 4 is a flowchart showing an example of database update processing executed by the core business server 200.
  • a process for updating the process flow data stored in the process flow DB 220 is executed in the core business server 200.
  • the core business server 200 acquires various process data and process flow data collected and organized by various information processing using various programs stored in the business application program DB 210 at a predetermined time. It shall be.
  • the core business server 200 determines whether or not new process flow data (new process flow data) has been acquired (step S101). If it is determined that new process flow data has not been acquired (N in step S101), the core business server 200 moves to the process in step S103 described later.
  • step S101 the core business server 200 registers the acquired process flow data in the process flow table PT (step S102).
  • the core business server 200 determines whether or not the process data corresponding to the registered process flow data (that is, data relating to the business process constituting the process flow) has been acquired (step S103).
  • process data acquired by the core business server 200 is registered process data is determined based on the process flow data including a combination of the process flow number and the process flow detail number of the acquired data. This is done by determining whether it is stored in the PT. For this reason, in this example, the data (that is, the process flow number) that constitutes the primary key part in the data acquired by the core business server (data input by the business executor or data created by the business application program). And the process flow item number).
  • the core business server 200 refers to the other DB 230 and sets a storage area corresponding to the acquired data.
  • the acquired data is registered (step S104), and the process proceeds to step S101.
  • the core business server 200 refers to the update condition table UT corresponding to the acquired process data and acquires the process data.
  • Update condition data corresponding to the process data is specified (step S105).
  • the core business server 200 specifies the update condition data based on the type of business process indicated by the process data and the process flow identification information (that is, the process flow number and the process flow detail number).
  • the core business server 200 determines whether or not the process flow data satisfies the update condition indicated by the specified update condition data (step S106). That is, the core business server 200 determines whether or not to register the acquired process data as part of the process flow data in the process flow table PT based on the process flow data and the update condition data. In this example, the core business server 200 compares the status part of the process flow data corresponding to the acquired process data with the update condition data, and the business process for which “1” is set in the update condition data is the status part. Also, in the case where all are set to “1”, it is determined that the process flow data satisfies the update condition.
  • step S107 the core business server 200 executes a predetermined error process (step S107), and the step The process proceeds to S101.
  • the “error processing” is not particularly limited as long as the process flow data is not updated. For example, even if the process data is temporarily stored in a predetermined storage area until the update condition is satisfied, Yes, processing to investigate the cause of acquiring process data that does not satisfy the update conditions (that is, the process of notifying the administrator of the error or the contents of the update condition that is not satisfied) Or the like).
  • the core business server 200 updates the process flow data registered in the process flow table PT. (That is, the acquired process data is registered in the process flow table PT) (step S108).
  • the core business server 200 determines whether or not a predetermined status change condition regarding the process flow data is satisfied by the update of the process flow data (step S109). If it is determined that the predetermined status change condition is not satisfied in response to the process flow data being updated (N in step S109), the core business server 200 moves to step S101.
  • step S109 if it is determined that the predetermined status change condition is satisfied in response to the process flow data being updated (Y in step S109), the core business server 200 determines that the process flow data is based on the satisfied status change condition. Is updated (step S110), and the process proceeds to step S101.
  • the database update process in this example is terminated by, for example, a termination operation by the administrator of the core business server 200.
  • the database update process may be a process executed in real time or a batch process executed every specific unit time.
  • a process having a part of real time property such as performing a real time process only for a specified period may be used.
  • FIG. 5 is a flowchart illustrating an example of a form output process executed by the core business server 200, the DWH server 300, and the client 10.
  • the core business server 200 displays process forms on the display screen of the client 10 by providing process flow data (part or all of the process flow data) to the client 10 via the DWH server 300.
  • the process for performing is performed. Since the client 10 and the client 20 are different only in the type of communication network, in this example, the case where the client 10 is used will be described as an example.
  • the DWH server 300 in this example only performs assistance (for example, client authentication) for communication between the core business server 200 and the client 10, description of the operation of the DWH server 300 will be omitted below. .
  • the process flow DB 220 update process described here is an example of the database update process (see FIG. 4).
  • the client 10 transmits a process flow data update request input screen request to the core business server 200 in response to, for example, an operation input by the user A of the client 10 (step S301).
  • the core business server 200 Upon receiving the process flow data update request input screen request, the core business server 200 transmits a process flow data update request input screen corresponding to the received process flow data update request input screen request (step S201).
  • the client 10 displays the process flow data update request input screen on the display screen of the display unit included in the client 10 (step S302).
  • FIG. 6 is an explanatory diagram showing an example of a process flow data update request input screen.
  • the process flow data update request input screen includes identification information to be updated (in this example, data corresponding to the main key part of the process flow data. That is, the process flow number and the process flow detail number). .)), A business process input area 12 for receiving an input of the type of business process indicated by the process data by the user A, and a detailed data input area for receiving input of the contents of other process data.
  • a return button 14 for receiving a request to switch the display screen output to the display unit to another display screen, and each input area (in this example, the main key data input area 11, the business process input area 12, the detailed data The process flow data update request based on the content input in the input area 13) is received.
  • Kicking and update button 15 is provided.
  • the client 10 When the client 10 accepts selection of any of the input areas by the cursor P that can be operated by a mouse operation, for example, the client 10 accepts input of text data (including numbers and characters) to the input area that has received the selection. Start. For example, when receiving input of text data using a keyboard, the client 10 displays the received text data in the selected area. In addition, when the client 10 accepts the selection of the business process input area 12, the client 10 displays a predetermined business process name in a pull-down format so that it can be selected. Note that the method for receiving input of process data is not limited to this, and for example, the client 10 may be configured to receive a plurality of process data collected in a predetermined data format at a time.
  • the client 10 determines that it has accepted a process flow data update request based on process data composed of data input to each input area (step S303).
  • the client 10 transmits the received update request to the core business server 200 (step S304).
  • the core business server 200 acquires process flow data corresponding to the received update request among the process flow data registered in the process flow table PT (step S202). At this time, the core business server 200 converts the process flow data including the primary key data indicated by the update request (that is, data input to the primary key data input area 11) into the update request (that is, the received process data). Acquired as corresponding process flow data. Further, “acquisition” here means temporarily storing the process flow data and the update condition data in a predetermined storage area in order to compare the process flow data with the update condition data.
  • the core business server 200 acquires the update condition data corresponding to the update request (step S203).
  • the update condition data corresponding to the update request is obtained by the business process and process flow data type indicated by the update request (that is, the business process input in the business process input area 12 and the processing in step S202). This means update condition data that can be specified by the type indicated by the process flow data (see FIG. 3).
  • the core business server 200 compares the acquired process flow data with the update condition data (step S204), and determines whether or not the process flow data update condition is satisfied (step S205). .
  • the update condition of the process flow data is satisfied because one or more of the items set to “1” in the update condition data is not set to “1” in the status part of the process flow data. If it is determined that there is not (N in Step S205), the core business server 200 creates an update error notification and transmits it to the client 10 (Step S206), and ends the processing here.
  • the client 10 displays the update error notification display screen on the display screen of the display unit included in the client 10 based on the received update error notification (step S306).
  • FIG. 7 is an explanatory diagram showing an example of an update error notification display screen.
  • the update error notification display screen is provided with an update error notification display area 21 that is displayed superimposed on the process flow data update request input screen.
  • the update error notification display area 21 in this example, in addition to the standard text for notifying the user A of the update error, a detail display button 22 for receiving a request to display details of the update condition, A close button 23 for receiving a request for deleting the update error notification display area 21 from the display screen is provided.
  • the user A can recognize the comparison result between the process flow data and the update condition data in the core business server 200 (for example, A comparison table showing the status part of the process flow data and the process flow data update condition of the update condition data.
  • step S205 Y the core business server 200 updates the process flow data by adding the process data indicated by the update request to the process flow data (step S207).
  • the core business server 200 transmits the updated process flow data to the client 10 (step S208), and ends the processing here.
  • the client 10 displays a form display screen on the display screen of the display unit included in the client 10 based on the received process flow data (step S307).
  • FIG. 8 is an explanatory diagram showing an example of a form display screen.
  • a form display area 31 for displaying a form based on the process flow data a form status display area 32, a return button 33, and a change button 34 are provided on the form display screen.
  • the client 10 changes the scale of the form displayed in the form display area 31 in accordance with, for example, an operation of a keyboard or the like provided in the client 10.
  • part or all of the process flow data is displayed in the form display area 31 in a predetermined display form.
  • information for displaying part or all of the process flow data in a predetermined display form is created by the core business server 200, and for example, at the timing of step S208 in the form output process, the client 10 Shall be sent to
  • the client 10 may be configured to display part or all of the received process flow data in the form display area 31 in a predetermined display format based on information stored in a storage device included in the client 10.
  • the form status display area 32 is an area for displaying the type (or status, hereinafter referred to as status) of the form displayed in the form display area 31.
  • status As the status of the form, various forms such as an order slip, a delivery slip, an inspection slip, and an invoice can be considered.
  • the return button 33 is a button for accepting a request to return the display screen to the process flow data update request input screen.
  • the client 10 accepts the selection of the return button 33 by the user A, not only the display screen is returned to the process flow data update request input screen but also the basic business server 200 based on the update request.
  • a configuration for transmitting a request to cancel the update of the process flow data may be used.
  • the client 10 has been input to each input area (in this example, the primary key data input area 11, the business process input area 12, and the detailed data input area 13) according to the selection of the return button 33.
  • the process flow data update request input screen may be displayed in a state indicating text data (the business process selected in the business process input area 12). With such a configuration, it is possible to easily confirm the input content by the user A.
  • the change button 34 is a button for accepting a request to change the display contents of the form display area 31.
  • the display content changing process in the form display area 31 will be described.
  • the client 10 determines whether or not the form status change request by the user A has been received (step S308).
  • the client 10 first receives selection of the form status display area 32 by the user A.
  • the client 10 displays a list of form status names indicating the forms of the forms that can be displayed in a pull-down format, for example. To do.
  • the core business server 200 determines the state of form data (form form data) and process flow data (that is, the input state of each column item of the process flow table PT) stored in a predetermined storage area in advance. ) To identify a form status name indicating the form of the form that can be displayed. That is, for example, when the type of process flow data transmitted to the client 10 is “inventory sales” and only process data related to the business process “order received” is registered in the process specific data section, the core business server 200 Specify only "order receipt” as the status name. If process data related to the business process “issue” is registered in addition to the process data related to the business process “order received”, the core business server 200 sets “order receipt slip” and “issue slip” as the form status names. Identify.
  • FIG. 9 is an explanatory diagram for explaining the transition of the form status based on the state of the process flow data.
  • images 101 to 104 are in the form of forms (specifically slips) that can be displayed in the form display area 31 based on the process flow data.
  • the images 101 to 104 are explanatory diagrams for explaining the transition of the form status, and do not show a specific description example for playing a role as various forms.
  • an image 104 will be described as an example.
  • an area 111 is a form status name
  • an area 112 is a process flow type
  • an area 113 is a business process name of process data included in the process flow data. It is assumed that it is an area to be shown (in this example, a character string display area).
  • a form status name corresponding to the type of process data included in the process flow data is displayed in the area 111.
  • the form status name (that is, the process The types of forms that can be displayed based on flow data will increase. This is not "whether or not there is the next type of form", but "the form status increases according to the state of the process flow data (that is, the types of forms that can be displayed increase)" means.
  • the client 10 receives the process flow data including the business process “order”, “shipment instruction”, “shipping”, and “shipping inspection” before the processing of step S307 in the form output processing.
  • the client 10 is the most out of the business processes “order”, “shipment instruction”, “shipping”, “shipping inspection” in the process flow indicated by the received process flow data.
  • the form corresponding to the form status name “order received slip” corresponding to the business process “order received” positioned at the upper level is displayed in the form display area 31 (see FIG. 8).
  • the client 10 may be configured to display in the form display area 31 a form corresponding to a business process corresponding to the process data newly added to the process flow data in the process of step S207.
  • step S308 If it is determined in the document status change request acceptance determination process (step S308) that the form status change request by the user A is not accepted (N in step S308), the client 10 proceeds to the process of step S310 described later.
  • the client 10 displays the form corresponding to the received change request in the form display area 31 (step S309).
  • the client 10 receives the selection of the form status name “issue slip” corresponding to the business process “issue” by the user A, and displays the form (issue slip) corresponding to the business process “issue” in the form display area. 31 is displayed.
  • the client 10 displays the form status name “issue slip” in the form status display area 32.
  • step S310 determines whether or not to end the form output process. If it is determined that the form output process is not to be ended (N in step S310), the client 10 proceeds to the process in step S308.
  • the client 10 ends the process here.
  • the database (for example, the process flow DB 220) includes a process including various data related to a process flow including a plurality of business processes (for example, a process flow of type “stock sales”). It includes a process flow table PT in which flow data is registered and an update condition table UT in which update condition data indicating process flow data update conditions are registered.
  • the process flow data includes status data, common data, and process-specific data.
  • Status data is data indicating the progress status of each of a plurality of business processes (for example, orders, shipping instructions, delivery, delivery inspection, sales) included in the process flow, and the common data is the same process Data common to the business processes included in the flow Data (for example, data indicating the order recipient and amount), the process-specific data is data specific to each business process included in the same process flow (for example, order date and order text), and the status data is The process-specific data is updated according to the update (for example, the corresponding status data is changed from “0” to “1” according to the addition of the process-specific data), and the update condition data is Since the configuration is data indicating the status data status, it is possible to reduce the processing load required for updating and retrieving data in the ERP system.
  • the common data is the same process Data common to the business processes included in the flow Data (for example, data indicating the order recipient and amount)
  • the process-specific data is data specific to each business process included in the same process flow (for example, order date and order text)
  • the status data is
  • FIG. 10 is an explanatory diagram for explaining the usefulness of the database update process executed by the basic business server 200 described above.
  • FIG. 10A is a table showing a comparison result of the data update amount when the first process data is input.
  • the type of process data to be input first that is, the type of business process
  • “conventional” means a database having a table for each business process, as shown in FIG.
  • “difference in data amount” does not indicate an exact numerical value, but a case where data stored in a conventional table is updated and a new type process flow table (that is, a process flow table PT, see FIG. 2).
  • the case where the amount of data handled by the new type increases is + ( Plus)
  • the case where the amount of data handled by the new type is smaller is ⁇ (minus)
  • the case where the amount of data handled by the new type and the conventional type can be regarded as the same is “0”.
  • the new type handles more data as much as the status part needs to be updated.
  • the data amount of the status portion is small, it can be said that there is substantially no difference in the amount of I / O data (input data and output data) between the conventional type and the new type.
  • FIG. 10B is a table showing a comparison result of the data update amount when the process data after the second process is input. That is, for example, the main key part, the reference key part, the type part, the status part, the common data part, and a part of the process specific data part (for example, process specific data “reception date”, “ “Order received text”) is a table showing a comparison result of the data update amount when the process data is input according to the business process included in the process flow already input in the process flow table PT.
  • “conventional type” defines other process data (for example, business process “shipment” corresponding to the process data (order data) registered in the order table, for example, in order to define the correspondence with the input process data.
  • the main key part, reference key part, type part, common data part, and process specific data part in this example are supported as the shipping instruction data.
  • the new type updates only the status part and the process specific data part as compared with the conventional type that requires all parts other than the status part. Therefore, the amount of I / O data is reduced.
  • the new type has a smaller amount of I / O data than the conventional type, which is advantageous in terms of system performance.
  • database I / O can be reduced, it is possible to reduce the amount of writing, reduce the capacity of the entire database, and reduce the processing load required for data search processing. .
  • one of the factors for reducing the processing load required for the search process is that the process (process data) does not extend over a plurality of tables.
  • the new type has the advantage that the input order of the process data can be made somewhat random. That is, for example, in the case of the type “inventory sales”, in the case of the conventional type, the order of the process flow is limited to the order of orders, shipping instructions, delivery, delivery inspection, and sales, and the order cannot be changed.
  • the relationship between business processes is expressed by assigning the primary key of the previous business process to the data of the subsequent business process (for example, in the shipping instruction table). “Order number” and “Order details” (see FIG. 12).
  • the new type table structure the data of related business processes is stored in the same entry (that is, the same column of the same table).
  • the order of business processes can be flexibly rearranged. That is, for example, when the actual business order is “order received after shipping instruction”, the process data input order can be made to conform to the actual business order. Therefore, it is advantageous over the conventional type in progress management (in other words, in internal control). Specifically, the current business order in the wholesale industry is “order received after shipping instruction”.
  • the contents of the update condition data can be set by, for example, a system administrator or a user, thereby preventing unauthorized process data from being input.
  • the update condition data for example, it is limited to the order in which there is a problem in internal control, such as "can record sales without a record of delivery" Can be provided, and the reliability of the database can be improved.
  • the load required to inquire about the progress of the process flow can be reduced. That is, when confirming how far the process flow has progressed, in the conventional table structure, it is necessary to confirm the registration status of all the tables from the start slip table to the final slip table. For example, when the type “inventory sales” is taken as an example, it is necessary to confirm five tables of orders, shipping instructions, delivery, delivery inspection and billing. On the other hand, since the new table structure has the progress status of the process flow as a “status part”, the progress can be confirmed only by querying one table and one entry. This is advantageous when using or developing a progress inquiry screen.
  • the database (for example, the process flow DB 220) is provided in the process flow data management server (for example, the core business server 200) that manages the process flow data generated for each process flow. Since the data management server is configured to provide part or all of the process flow data to the client terminal in response to a request from the client terminal (for example, the clients 10 and 20), It is possible to construct a system in which the processing load required for providing the process flow data indicating the form information necessary for creation is reduced as compared with the conventional system.
  • the process flow data management server (for example, the core business management server 200) accepts input of process data that is data related to each of a plurality of business processes, and accepts it based on the update condition data. It is determined whether or not process data (for example, process data indicated by a process flow data update request) is registered as part of the process flow data (for example, determination of whether or not the process flow data satisfies an update condition.
  • process data for example, process data indicated by a process flow data update request
  • the process flow data registered in the process flow table PT is updated in response to the determination that the process data is to be registered. Can be prevented.
  • the process flow data management server determines that the process data is not registered, and the update condition is not satisfied.
  • a certain unsatisfied update condition is specified, the specified unsatisfied update condition is notified to the client terminal (for example, the client 10, 20), and at a predetermined timing, it is determined whether the update condition specified as the unsatisfied update condition is satisfied.
  • the process data corresponding to the update condition may be registered in the process flow table PT when it is determined that the update condition specified as the unsatisfied update condition is satisfied.
  • the progress determination in which the database (for example, the process flow DB 220) registers progress determination condition data that is data indicating the determination condition of the progress of the process flow.
  • the process flow data management server (for example, the core business server 200) includes a condition table, and status data (for example, data stored in the status part of the process flow table PT, see FIG. 2) based on the progress determination condition. It is good also as a structure which judges whether progress condition determination conditions are satisfy
  • FIG. 11 is an explanatory diagram showing an example of the storage status of the progress status determination condition data stored in the progress status determination condition table.
  • the progress determination condition data in this example includes a process flow type and a progress determination condition according to the process flow type.
  • the process flow type includes sample shipment, service sales, name change (sales), name change (shipment), sales return (with original transaction reference), sales return (original transaction reference) None), sales amount adjustment (plus), sales amount adjustment (minus), etc.
  • the “progress status determination condition” indicates a criterion for determining the progress status of the process flow.
  • a business process for example, order, shipping instruction, delivery, etc.
  • the core business server 200 determines that the process flow data entry is in the “completed” state. A determination is made (that is, it is determined that the process flow indicated by the process flow data has been completed), and a process (notification process) for notifying that effect to a predetermined client (for example, the clients 10 and 20) is performed.
  • This configuration makes it possible to construct a system that can determine the status of business execution.
  • start timing of the progress status determination process or the notification process may be when there is a request from the client terminal, or may be a preset timing.
  • the progress status determination condition data is configured to include a completion condition for determining whether the process flow has been completed.
  • a system can be constructed.
  • the progress status determination condition data is not limited to data for determining that the process flow is in the “completed” state, and includes, for example, data for determining that the process flow is in the “50% complete” state. It is good also as a structure.
  • the progress status determination condition data may be configured to indicate the type of process data that should be input before a predetermined time elapses from the input of the first process data.
  • the database receives at least one of the data registered in the process flow table PT in response to the input of predetermined data. It is good also as a structure which provides the restriction
  • a change for example, deletion or overwriting of data
  • the common data part may not be changed freely after the process specific data related to the process “exit / acceptance” is registered in the process flow table PT.
  • a configuration may be adopted in which restrictions such as a password to be input and conditions to be satisfied when the user changes the contents of the common data portion are added.
  • PT process flow table UT update condition table 10 client 20 client 51 leased line 52 LAN 53 Internet 200 Core Business Server 210 Business Application Program DB 220 Process Flow DB 230 Other DB 300 DWH server 500 Integrated mission-critical system

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

　ＥＲＰシステムにおけるデータの更新や検索に要する処理負荷を軽減させる。　データベースが、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータが登録されるプロセスフローテーブルＰＴと、プロセスフローデータの更新条件を示す更新条件データが登録される更新条件テーブルＵＴとを備え、プロセスフローデータが、プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すステータスデータと、同一のプロセスフローに含まれる業務プロセス間で共通する共通データと、同一のプロセスフローに含まれる各業務プロセスに固有のプロセス固有データとを含み、ステータスデータが、プロセス固有データが更新されたことに応じて更新され、更新条件データは、ステータスデータの状態を示すデータである構成とする。

Description

データベース、データ管理サーバ、およびデータ管理プログラム
　本発明は、ＥＲＰシステムにて利用可能なデータベース、このデータベースを備えるデータ管理サーバ、およびデータ管理サーバに搭載されるデータ管理プログラムに関する。
　従来から、企業における基幹業務システムを構築するためのパッケージソフトウェアとして、ＥＲＰ（Enterprise Resource Planning）（または、ＥＲＰパッケージ）と呼ばれるものが利用されている。
　このＥＲＰが搭載されたシステムとして、企業における販売管理、購買管理、在庫管理、生産管理、財務会計、管理会計といった基幹業務をリアルタイムに連携させ、各業務に関する情報を一元的に管理することを可能としたものが広く知られている。
　このようなシステム（ＥＲＰシステム、または統合基幹業務システム）には、例えば、経営資源の情報管理を行い、予め定められた第１のデータフォーマットによる情報の通信を行う統合業務システムに、第１のデータフォーマットとは異なる第２のデータフォーマットによる情報の通信を行う複数の情報装置とに接続されたデータ変換装置であって、統合業務システムから出力される第１のデータフォーマットによる情報の入力を受け付け、受け付けた情報を第２のデータフォーマットに変換して情報装置に送信するデータ変換装置を組み込む構成とすることにより、システムの利便性を高めようとするものもがある（特許文献１参照）。
特開２００９―０９９０７０号公報
　しかしながら、従来のＥＲＰシステムでは、各業務プロセスにおいて取得されるデータ（ユーザにより入力されるデータと各種データから算出されるデータとを含む）を、それぞれ専用のデータテーブル（テーブル）に登録し、管理している。すなわち、従来のＥＲＰシステムにおいては、受注や出荷指示などの入力プロセス毎に、更新するテーブルが異なる。なお、「入力プロセス」とは、各業務プロセスにおいてＥＲＰシステムの管理者などが取得（または決定）した各種データを、各テーブルに入力する処理を意味する。
　図１２は、従来のＥＲＰシステムにおけるテーブル構成の例について説明するための説明図である。例えば、複数の業務プロセスにより構成される業務フロー（プロセスフロー）が「在庫売上」を示すものである場合、入力プロセスは、受注、出荷指示、出庫、検収、および売上の５つとなる。この場合、「在庫売上」のプロセスフローに関するデータを格納するテーブルは、例えば図１２（Ａ）から図１２（Ｅ）に示すように、入力プロセス毎にそれぞれ、受注テーブル、出荷指示テーブル、出庫テーブル、検収テーブル、および売上テーブルの５つとなる。
　すなわち、従来のＥＲＰシステムでは、入力プロセス毎に更新するテーブルが異なっていた。そのため、同一のプロセスフローに属する複数の業務プロセス間の対応付けは、各業務プロセスに関するデータ（プロセスデータ）に対して識別子（図１２においては、出荷指示テーブルにおける受注番号と受注明細や、出庫テーブルにおける出荷指示番号と出荷指示明細など）を付与することにより行われていた。
　そのため、従来のＥＲＰシステムでは、１つの入力プロセスに対して、入力プロセスの種類に応じたテーブルの特定と、対応する他のプロセスデータの識別子の入力とが必要となっていた。すなわち、例えば図１２に示す場合に、受注番号「Ａ００００１」と受注明細番号「００１０」とで特定されるプロセスデータ（すなわち、受注テーブルにおいて受注番号「Ａ００００１」と受注明細番号「００１０」と同一列に格納された各種データ）に関連する業務プロセス「出荷指示」に関するプロセスデータをＥＲＰシステムが備えるデータベースに登録する場合、業務プロセス「出荷指示」に関するプロセスデータとして、プロセスデータを特定するための出荷指示番号と出荷指示明細番号、業務プロセスの種類を示すタイプ、および業務プロセスの内容を示すデータ（例えば、受注先、数量、金額、出荷指示日、出荷テキストなど）と共に、受注番号「Ａ００００１」と受注明細番号「００１０」とを出荷指示テーブルに登録する必要があった。これは、複数のテーブルに一部同一のデータ（例えば、受注先や数量、金額など）が登録されてしまうことなど、効率的なデータ処理の観点からみて問題があった。
　また、従来のＥＲＰシステムでは、各種テーブルに格納された各種データを用いてユーザの要求に応じた帳票を作成しようとする場合、プロセスデータの識別子を辿って必要なプロセスデータを検索し、それぞれ別個に取得する必要があるため、プロセスフローが多数の業務プロセスを含む場合、プロセスフローに関する帳票を出力するために要する処理負荷が過大になってしまうという問題があった。
　本発明は、上述した問題を解消し、ＥＲＰシステムにおけるデータの更新や検索に要する処理負荷を軽減させることをできるようにすることを目的とする。
　本発明のデータベースは、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータが登録されるプロセスフローテーブルと、前記プロセスフローデータの更新条件を示す更新条件データが登録される更新条件テーブルとを備え、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記ステータスデータは、前記プロセス固有データが更新されたことに応じて更新され、前記更新条件データは、前記ステータスデータの状態を示すデータであることを特徴とする。
　上記の構成としたことで、ＥＲＰシステムにおけるデータの更新や検索に要する処理負荷を軽減させることができるようになる。
　前記プロセスフロー毎に発生するプロセスフローデータを管理するプロセスフローデータ管理サーバに備えられ、該プロセスフローデータ管理サーバは、クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段を含む構成とされていてもよい。
　前記プロセスフローデータ管理サーバは、前記複数の業務プロセスそれぞれに関するデータであるプロセスデータの入力を受け付けるプロセスデータ受付手段と、前記更新条件データに基づいて、前記プロセスデータ受付手段により受け付けられたプロセスデータを前記プロセスフローデータの一部として登録するか判定する登録判定手段と、該登録判定手段により前記プロセスデータを登録するものと判定されたことに応じて、前記プロセスフローテーブルに登録されたプロセスフローデータを更新するプロセスフローデータ更新手段とを含む構成とされていてもよい。
　前記プロセスフローデータ管理サーバは、前記登録判定手段により前記プロセスデータを登録しないと判定されたことに応じて、満たされていない更新条件である非充足更新条件を特定する非充足更新条件特定手段と、該非充足更新条件特定手段により特定された非充足更新条件を前記クライアント端末に報知する報知手段と、所定のタイミングで、前記非充足更新条件として特定された更新条件が満たされたか判定する充足判定手段とを含み、前記プロセスフローデータ更新手段は、前記充足判定手段により前記非充足更新条件として特定された更新条件が満たされたと判定されたことに応じて、当該更新条件に対応するプロセスデータを前記プロセスフローテーブルに登録する構成とされていてもよい。
　また、本発明のデータ管理サーバは、クライアント端末に対して各種データを提供するデータ管理サーバであって、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータと、該プロセスフローデータの更新条件を示す更新条件データとを記憶するプロセスフローデータ記憶手段と、前記プロセスフローの進捗状況に応じて当該プロセスフローデータを更新するプロセスフローデータ更新手段と、前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段とを含み、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記更新条件データは、前記ステータスデータの状態を示すデータであり、前記プロセスフローデータ更新手段は、前記更新条件データに基づいて前記プロセスフローデータを更新することを特徴とする。
　さらに、本発明のデータ管理プログラムは、クライアント端末に対して各種データを提供するようにデータ管理サーバに動作制御させるためのデータ管理プログラムであって、前記データ管理サーバに、複数の業務プロセスを含むプロセスフローの進捗状況に応じて前記プロセスフローに関する各種データを含むプロセスフローデータと該プロセスフローデータの更新条件を示す更新条件データとを記憶するプロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新するプロセスフローデータ更新処理と、前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供処理とを実行させ、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記更新条件データは、前記ステータスデータの状態を示すデータであり、前記プロセスフローデータ更新処理にて、前記更新条件データに基づいて前記プロセスフローデータを更新する処理を実行させるためのものである。
　本発明によれば、ＥＲＰシステムにおけるデータの更新や検索に要する処理負荷を軽減させることができるようになる。
本発明の一実施の形態における統合基幹業務システムの構成例を示すブロック図である。 プロセスフローデータの格納状態の例を示す説明図である。 更新条件データの格納状態の例を示す説明図である。 データベース更新処理の例を示すフローチャートである。 帳票出力処理の例を示すフローチャートである。 プロセスフローデータ更新要求入力画面の例を示す説明図である。 更新エラー通知表示画面の例を示す説明図である。 帳票表示画面の例を示す説明図である。 プロセスフローデータの状態に基づく帳票ステータスの遷移について説明するための説明図である。 データベース更新処理の有用性について説明するための説明図である。 進捗状況判定条件データの格納状態の例を示す説明図である。 従来のＥＲＰシステムにおけるテーブル構成の例について説明するための説明図である。
　以下、本発明の一実施の形態の例について図面を参照して説明する。
　図１は、本発明の一実施の形態に係る統合基幹業務システム５００の構成例を示すブロック図である。図１に示すように、統合基幹業務システム５００は、基幹業務サーバ２００と、データウェアハウスサーバ（ＤＷＨサーバ）３００と、クライアント１０と、クライアント２０とを含む。統合基幹業務システム５００を構成する各要素は、それぞれ通信ネットワークにより接続される。
　本例においては、基幹業務サーバ２００とＤＷＨサーバ３００とは、専用回線５１により接続されているものとする。また、クライアント１０は、ＬＡＮ（Local Area Network）５２によりＤＷＨサーバ３００と接続されている。また、クライアント２０は、インターネット５３によりＤＷＨサーバ３００と接続されている。
　基幹業務サーバ２００は、例えば統合基幹業務システム５００の管理者によって管理されるサーバであり、各種業務に関する帳票情報など、各種業務プロセスにおける情報を示すデータであるプロセスデータを管理するための各種機能を有する。なお、本例における基幹業務サーバ２００は、ＯＳ（Operating System）やリレーショナルデータベース（リレーショナルＤＢ）を備えた一般的な情報処理装置によって構成される。
　ここで、帳票とは、帳簿や伝票類の総称である。また、帳簿とは、金銭や品物の出納に関する事項が記入されるものであり、伝票とは、帳簿を作成する際の基となるデータであり業務上の取引等の証拠となるものである。なお、基幹業務サーバ２００が、例えば、各種伝票の作成に用いる伝票情報のみを示すプロセスデータを扱う構成としてもよい。
　また、本例における基幹業務サーバ２００は、図１に示すように、業務アプリケーションプログラムＤＢ２１０と、プロセスフローＤＢ２２０と、一般的な基幹業務サーバとしての機能を実現するために必要な各種データ（例えば、業務アプリケーションプログラムＤＢ２１０に格納される各種プログラムが利用するデータ）を格納するその他ＤＢ２３０とを備えている。なお、その他ＤＢ２３０については、本発明に特に関係しない部分であるため、詳しい説明は省略する。
　業務アプリケーションプログラムＤＢ２１０は、各種業務に用いられるプログラムを記憶する記憶媒体である。業務アプリケーションプログラムＤＢ２１０に記憶されるプログラムとしては、販売業務管理プログラム、購買業務管理プログラム、生産管理プログラム、財務会計管理プログラム、および管理会計管理プログラムなどがある。
　プロセスフローＤＢ２２０は、業務アプリケーションプログラムＤＢ２１０に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータ（または帳票データ）により構成されるプロセスフローデータを記憶する記憶媒体である。本例においては、プロセスフローＤＢ２２０において、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータがプロセスフローテーブルＰＴに格納される場合について説明する。また、本例においては、基幹業務サーバ２００が、プロセスフロー毎に発生するプロセスフローデータを１つのプロセスフローテーブルＰＴにて一元管理する場合について説明する。
　なお、基幹業務サーバ２００が、プロセスフローデータを、例えば、後述するタイプ毎に、あるいは後述する共通データの内容の一部（例えば、受注先など）が同じもの毎に、複数のテーブルで管理する構成としてもよい。
　図２は、プロセスフローＤＢ２２０におけるプロセスフローデータの格納状態の例を示す説明図である。図２に示すように、本例におけるプロセスフローデータは、主キー部と、参照キー部と、タイプ部と、ステータス部と、共通データ部と、プロセス固有データ部とを含む。なお、プロセスフローデータの各部に対応する項目（すなわち、プロセスフローテーブルＰＴにおける各列項目）が、それぞれ、プロセスフローデータを構成するプロセスデータの種類を示す。すなわち、プロセスフローを構成する各業務プロセスに関するデータは、プロセスフローデータを構成する各部に割り当てられて格納される。なお、１つのプロセスフロー（例えば、ある企業からの受注から納品までの一連のプロセスフロー）に関するプロセスデータは、プロセスフローテーブルＰＴにおいて同一エントリ（すなわち、プロセステーブルＰＴにおける同一行）に格納される。このような構成とすることにより、各プロセスデータ間の対応関係を定義することができる。
　ここで、「主キー部」とは、プロセスフローデータのうち、プロセスフローデータを一意に特定するためのデータである主キーデータが格納される部分である。本例においては、主キー部は、プロセスフロー番号とプロセスフロー明細番号とにより構成される。すなわち、本例においては、プロセスフロー番号とプロセスフロー明細番号との組み合わせが、各プロセスフローデータの識別子（ＩＤ）となる。主キー部は、プロセスフローデータの初回登録時に更新される。なお、ここでの「プロセスフローデータの初回登録時」とは、プロセスフローデータにエントリ（データ行）が追加されるとき、例えば、あるプロセスフローに属するプロセスデータであって、対応する他のプロセスデータが未登録のプロセスデータが登録されるときを意味するものとする。また、ここでの「更新」とは、データの追加を含むものとする。
　なお、「プロセスフロー番号」とは、１つのプロセスフローデータ（すなわち、図２に示すプロセスフローテーブルＰＴにおける１列）を特定するための識別子である。プロセスフロー番号は、所定の項目が同じプロセスデータ毎に付与される。本例においては、プロセスフロー番号は、プロセスフローデータにおけるタイプと受注先とが同じプロセスフローデータに対して同一の番号が付与される。
　また、「プロセスフロー明細番号」とは、同一のプロセスフロー番号が付与されたプロセスフローデータの中から特定のプロセスフローデータを特定するための識別子である。すなわち、例えば図２に示すプロセスフローテーブルＰＴは、プロセスフローのタイプ「在庫売上」における業務プロセス「受注」において、受注先「Ｔ００１」から金額「１２００」と「２６００」の業務を受注したことを示すプロセスデータを含むプロセスフローデータを、それぞれプロセスフロー番号「０００００１」とプロセスフロー明細番号「００１０」または「００２０」の組み合わせにより一意に特定することができる。
　次いで、「参照キー部」とは、プロセスフローデータのうち、売上返品に対する元取引など、プロセスフローに関連する他のプロセスフローデータ（または、他のプロセスデータ）を特定するためのデータである参照キーデータが格納される部分である。本例においては、参照キー部は、参照番号と参照明細番号とにより構成される。参照キー部は、プロセスフローデータの初回登録時に更新される。
　なお、参照番号と参照明細番号には、それぞれ、プロセスフローに関連する他のプロセスフローのプロセスフロー番号とプロセスフロー明細番号とが格納される。ただし、新規取引の場合など、プロセスフローに関連する他のプロセスフローがない場合には、参照キー部には、同一エントリの主キー部と同じ値を示すデータが（すなわち、参照番号にはプロセスフロー番号が、参照明細番号にはプロセスフロー明細番号がそれぞれ）格納される。また、参照キー部が、プロセスフローに関連する他のプロセスデータを示す場合、参照キー部には、プロセスデータの種類を特定するためのデータがさらに設けられる。
　また、「タイプ部」とは、プロセスフローデータのうち、在庫売上やサンプル出荷など、プロセスフローの種類を示すデータであるタイプデータが格納される部分である。タイプ部は、プロセスフローデータの初回登録時に更新される。なお、プロセスフローの種類は、在庫売上やサンプル出荷に限られない。また、プロセスフローの種類毎にどのプロセスが必要なのかが予め決まっているものとする（すなわち、プロセスフローの種類毎に含まれる業務プロセスの種類や数が異なる）。なお、プロセスフローの他の種類については、後で複数提示する（図１１参照）。
　また、「ステータス部」とは、プロセスフローデータのうち、プロセスフローの進捗を表すデータ（すなわち、プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータ）であるステータスデータが格納される部分である。本例においては、ステータスデータは、プロセスフローが必要とする業務プロセスに対し、未済のものには「０」、既済のものには「１」が設定されることにより、各業務プロセスの進捗を示す。すなわち、例えば図２に示すように、「在庫売上」のプロセスフローであって、プロセスフローに含まれる業務プロセスが「受注」、「出荷」、「出庫」、「出庫検収」、および「売上」である場合に、業務プロセス「受注」に関するプロセス固有データ（例えば、受注日）が登録されたとする。この場合、ステータスデータは、「売上」に対応する部分が「１」になり、その他の部分は初期状態（すなわち、「０」が設定された状態）のままとなる。
　すなわち、本例におけるステータス部は、各業務プロセス毎に更新される。言い換えれば、ステータス部は、後述するプロセス固有データの入力のとき、具体的には、所定のステータス変更条件が満たされたことにより各業務プロセスが完了した判定されたときに更新される。なお、ステータス変更条件は特に限定されないが、本例においては、「１つの業務プロセスに対応するプロセス固有データが全て入力されること」がステータス変更条件として基幹業務サーバ２００の所定の記憶領域に記憶されているものとする。
　なお、本例においては、異なる種類のプロセスフローが同一のテーブルに格納されるため、テーブルを構成する項目（列項目）のうち、特定のプロセスフローには不要なプロセスデータを格納する部分が生じる場合もある。この場合、プロセスフローテーブルにおいては、不要なプロセスデータを格納する部分が空データとなり、空データに対応するステータスデータには「０」が格納されるものとする。
　また、「共通データ部」とは、プロセスフローデータのうち、受注先や出荷先など、業務プロセスによらないデータ（すなわち、同一のプロセスフローに含まれる業務プロセス間で共通するデータ）である共通データが格納される部分である。共通データ部は、プロセスフローデータの初回登録時に更新される。
　また、「プロセス固有データ部」とは、プロセスフローデータのうち、受注日や各業務プロセスにおいて登録されるデータ（例えば、「納期必着」や「ワレモノ（割れ物注意）」などの注意事項を示すテキストデータ）など、同一のプロセスフローに含まれる各業務プロセスに固有のデータであるプロセス固有データが格納される部分である。プロセス固有データ部は、各業務プロセス毎に更新される。よって、本例においては、プロセスフローデータのうち、業務プロセスによるものが「プロセス固有データ」であり、業務プロセスによらないものが「共通データ」であるといえる。
　以上が本例におけるプロセスフローデータに関する説明となるが、ここで、図２に示す各種用語の定義について簡単に説明する。
　先ず、「受注」とは、得意先から注文を受け、得意先との契約を結んだ状態を意味する。また、「出荷指示」とは、倉庫業者や物流担当者に商品を出荷する指示を行った状態を意味する。また、「出庫」とは、商品が倉庫から出荷され、移動が開始された状態を意味する。また、「検収」とは、得意先の検収が完了し、商品の所有権が得意先に移行した状態を意味する。また、「売上」とは、得意先の検収を確認し、得意先に対する債権金額が確定（＝債権を計上）した状態を意味する。
　また、「検収」の用語は、「納入品やサービスが、注文通りの仕様（＝注文通りの数量、色や形、品質）になっているかを検査する業務」や「検収完了時、資産の所有権が移行する」という意味でも用いられる。なお、財務会計上（または、制度会計上）やＥＲＰシステム上では、資産の所有権の移行タイミングを明確にするために、「検収」というイベントが出庫と区別して定義される。
　また、本例においては、プロセスフローＤＢ２２０には、プロセスフローデータ（または、プロセスフローテーブルＰＴ）の更新条件を示す更新条件データが登録される更新条件テーブルＵＴが備えられる。
　図３は、プロセスフローＤＢ２２０における更新条件データの格納状態の例を示す説明図である。図３に示すように、本例における更新条件データは、業務プロセスの名称と、プロセスフローのタイプと、プロセスフローデータ更新条件とを含む。
　ここで、「プロセスフローデータ更新条件」とは、プロセスフローのタイプに応じたプロセスデータの登録条件を示すものである。本例においては、プロセスフローデータ更新条件は、ある業務プロセスに関するプロセスデータをプロセスフローデータに追加する場合に、その前提としてプロセスフローデータが有しているべきプロセスデータの種類（すなわち、プロセスフローにおいて完了しているべき業務プロセスの種類）を示す。すなわち、更新条件テーブルＵＴが図３に示したものである場合、例えば業務プロセス「出庫検収」に関するプロセスデータがタイプ「在庫売上」のプロセスフローデータに追加されるには、予め定められた業務プロセス「受注」、「出荷指示」、および「出庫」（すなわち、図３において業務プロセス名称「出庫検収」とタイプ「在庫売上」と同一列のセルに「１」が設定された業務プロセス）に関するプロセスデータがプロセスフローデータに登録されている必要がある。なお、更新条件テーブルＵＴは、統合基幹業務システム５００の管理者によって作成される構成としてもよいし、クライアント１０，２０のユーザにより作成可能な構成とされていてもよい。
　基幹業務サーバ２００は、プロセスフローＤＢ２２０およびその他ＤＢ２３０に格納された各種データを、所定の抽出条件に応じてＣＳＶ
（Comma Separated Values）形式に変換してＤＷＨサーバ３００に送信する機能を有する。なお、本例においては、基幹業務サーバ２００は、ＦＴＰ（File Transfer Protocol）によりＣＳＶ形式にしたデータファイルをＤＷＨサーバ３００に転送する。
　ＤＷＨサーバ３００は、例えば本システムのシステム管理者によって管理されるサーバであり、データウェアハウスを実現するための各種の機能を有する。ここで、「データウェアハウス」とは、時系列で蓄積された帳票データなどの業務データ（本例においては、プロセスフローデータ）の中から各項目間の関連性を分析するシステムをいう。また、ＤＷＨサーバ３００は、基幹業務サーバ２００から転送されたＣＳＶ形式のファイルを所定のデータ形式に変換するなどして、所定の格納領域に各種データを登録する機能を有する。なお、ＤＷＨサーバ３００は、データ形式の変換を行わず、ＣＳＶ形式の状態から各格納領域に応じたデータを抽出する構成とされていてもよい。
　クライアント１０，２０は、ＣＰＵ（中央処理装置）、ＲＯＭ、ＲＡＭ、および表示部などを備えた情報処理装置（クライアント端末）である。本例においては、クライアント１０，２０は、Ｗｅｂブラウザや表計算ソフトなど、帳票データを扱うために利用可能な各種アプリケーションを有しているものとする。また、本例においては、クライアント１０，２０は、例えばユーザによる操作入力に応じて、ＤＷＨサーバ３００から必要な帳票データ（本例においては、プロセスフローデータ）を取得するためのクエリ（検索項目、検索キー、抽出キーなど）を定義し、ＤＷＨサーバ３００に送信する機能を有する。
　本例においては、クライアント１０は、ＬＡＮを介してＤＷＨサーバ３００と通信し、ＤＷＨサーバ３００から取得したデータを所定の表計算ソフトによって表示部に出力する機能を有する。
　また、クライアント２０は、インターネットを介してＤＷＨサーバ３００と通信し、ＤＷＨサーバ３００から取得したデータをＷｅｂブラウザによって表示部に出力する機能を有する。
　なお、本例においては、クライアント１０，２０は、基幹業務サーバ２００のプロセスフローＤＢ２２０に記憶されるプロセスフローデータに基づいて、所定の形態を有する帳票を自己が備える表示部に出力する機能を有する。
　なお、統合基幹業務システム５００の構成はこれに限定されず、例えば、クライアント１０，２０と基幹業務サーバ２００とが、ＤＷＨサーバ３００を介さずに直接データの送受信を行える構成とされていてもよい。すなわち、クライアント１０，２０が、プロセスフローＤＢ２２０Ｂに直接アクセス可能な構成とされていてもよい。
　次に、統合基幹業務システム５００における基幹業務サーバ２００の動作について図面を参照して説明する。なお、本発明に特に関係しない動作や処理については、その内容を省略している場合がある。
　図４は、基幹業務サーバ２００が実行するデータベース更新処理の例を示すフローチャートである。データベース更新処理では、基幹業務サーバ２００にてプロセスフローＤＢ２２０に記憶されたプロセスフローデータを更新するための処理が実行される。なお、本例においては、基幹業務サーバ２００は、業務アプリケーションプログラムＤＢ２１０に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータやプロセスフローデータを所定の時機に取得するものとする。
　データベース更新処理において、先ず、基幹業務サーバ２００は、新たなプロセスフローデータ（新規プロセスフローデータ）を取得したか否かを判定する（ステップＳ１０１）。ここで、新規プロセスフローデータを取得していないと判定すると（ステップＳ１０１のＮ）、基幹業務サーバ２００は、後述するステップＳ１０３の処理に移行する。
　一方、新規プロセスフローデータを取得したと判定すると（ステップＳ１０１のＹ）、基幹業務サーバ２００は、取得したプロセスフローデータをプロセスフローテーブルＰＴに登録する（ステップＳ１０２）。
　次いで、基幹業務サーバ２００は、登録済みのプロセスフローデータに対応するプロセスデータ（すなわち、プロセスフローを構成する業務プロセスに関するデータ）を取得したか否かを判定する（ステップＳ１０３）。
　なお、基幹業務サーバ２００による取得したプロセスデータが登録済みのプロセスデータである否かの判定は、取得したデータが有するプロセスフロー番号とプロセスフロー明細番号との組み合わせを有するプロセスフローデータがプロセスフローテーブルＰＴに格納されているか否かを判定することにより行う。そのため、本例においては、基幹業務サーバが取得するデータ（業務の実行者により入力されたデータ、または業務アプリケーションプログラムにより作成されたデータ）に、主キー部を構成するデータ（すなわち、プロセスフロー番号とプロセスフロー明細番号）が含まれることが必要となる。
　ここで、登録済みのプロセスフローデータに対応するプロセスデータを取得していないと判定すると（ステップＳ１０３のＮ）、基幹業務サーバ２００は、その他ＤＢ２３０を参照し、取得したデータに対応する記憶領域を特定して、取得したデータを登録し（ステップＳ１０４）、ステップＳ１０１の処理に移行する。
　一方、登録済みのプロセスフローデータに対応するプロセスデータを取得したと判定すると（ステップＳ１０３のＹ）、基幹業務サーバ２００は、取得したプロセスデータに対応する更新条件テーブルＵＴを参照して、取得したプロセスデータに応じた更新条件データを特定する（ステップＳ１０５）。本例においては、基幹業務サーバ２００は、プロセスデータが示す業務プロセスの種類とプロセスフローの識別情報（すなわち、プロセスフロー番号とプロセスフロー明細番号）に基づいて更新条件データを特定する。
　更新条件データを特定すると、基幹業務サーバ２００は、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしているか否か判定する（ステップＳ１０６）。すなわち、基幹業務サーバ２００は、プロセスフローデータと更新条件データとに基づいて、取得したプロセスデータをプロセスフローデータの一部としてプロセスフローテーブルＰＴに登録するか否か判定する。本例においては、基幹業務サーバ２００は、取得したプロセスデータに対応するプロセスフローデータのステータス部と更新条件データとを比較し、更新条件データにて「１」が設定された業務プロセスがステータス部においても全て「１」に設定されている場合に、プロセスフローデータが更新条件を満たしていると判定する。
　ここで、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしていないと判定すると（ステップＳ１０６のＮ）、基幹業務サーバ２００は、所定のエラー処理を実行し（ステップＳ１０７）、ステップＳ１０１の処理に移行する。なお、「エラー処理」とは、プロセスフローデータを更新しない処理であれば特に限定されず、例えば、更新条件が満たされるまでプロセスデータを所定の記憶領域に一時的に保存する処理であってもよいし、更新条件を満たしていないプロセスデータを取得することとなった原因を調べるための処理（すなわち、エラーを管理者に報知する処理や、充足されていない更新条件の内容を管理者に報知する処理など）などであってもよい。
　一方、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしていると判定すると（ステップＳ１０６のＹ）、基幹業務サーバ２００は、プロセスフローテーブルＰＴに登録されたプロセスフローデータを更新する（すなわち、取得したプロセスデータをプロセスフローテーブルＰＴに登録する）（ステップＳ１０８）。
　プロセスフローデータを更新すると、基幹業務サーバ２００は、プロセスフローデータの更新によりプロセスフローデータに関する所定のステータス変更条件が満たされたか否かを判定する（ステップＳ１０９）。ここで、プロセスフローデータが更新されたことに応じて所定のステータス変更条件が満たされていないと判定すると（ステップＳ１０９のＮ）、基幹業務サーバ２００は、ステップＳ１０１に移行する。
　一方、プロセスフローデータが更新されたことに応じて所定のステータス変更条件が満たされたと判定すると（ステップＳ１０９のＹ）、基幹業務サーバ２００は、満たされたステータス変更条件に基づいて、プロセスフローデータが含むステータスデータを更新し（ステップＳ１１０）、ステップＳ１０１の処理に移行する。
　本例におけるデータベース更新処理は、例えば、基幹業務サーバ２００の管理者による終了操作により終了する。
　また、データベース更新処理は、リアルタイムに実行される処理であってもよいし、特定の単位時間毎に実行されるバッチ処理であってもよい。また、例えば指定された期間だけリアルタイム処理を行うような、一部にリアルタイム性を有した処理（準リアルタイム処理）であってもよい。
　次に、本例の統合基幹業務システム５００における基幹業務サーバ２００とＤＷＨサーバ３００とクライアント１０，２０の動作について図面を参照して説明する。なお、本発明に特に関係しない動作や処理については、その内容を省略している場合がある。
　図５は、基幹業務サーバ２００と、ＤＷＨサーバ３００と、クライアント１０とが実行する帳票出力処理の例を示すフローチャートである。帳票出力処理では、基幹業務サーバ２００が、ＤＷＨサーバ３００を介してクライアント１０に対しプロセスフローデータ（プロセスフローデータの一部または全部）を提供することにより、クライアント１０が備える表示画面に帳票を表示するための処理が実行される。なお、クライアント１０とクライアント２０では、通信ネットワークの種類が異なるだけなので、本例においてはクライアント１０を用いる場合を例に説明を行なう。また、本例におけるＤＷＨサーバ３００は、基幹業務サーバ２００とクライアント１０とが通信を行うための補助（例えば、クライアントの認証など）を行うだけなので、以下ＤＷＨサーバ３００の動作についての説明は省略する。
　また、本例においては、クライアント１０からの要求に応じて、基幹業務サーバ２００がプロセスフローデータを更新する場合についての説明も行う。なお、本例においては、ここで説明するプロセスフローＤＢ２２０の更新処理（すなわち、帳票出力処理におけるプロセスフローＤＢ２２０の更新処理）は、データベース更新処理（図４参照）の１例である。
　帳票出力処理において、先ず、クライアント１０は、例えばクライアント１０のユーザＡによる操作入力に応じて、プロセスフローデータ更新要求入力画面要求を基幹業務サーバ２００に送信する（ステップＳ３０１）。
　プロセスフローデータ更新要求入力画面要求を受信すると、基幹業務サーバ２００は、受信したプロセスフローデータ更新要求入力画面要求に応じたプロセスフローデータ更新要求入力画面を送信する（ステップＳ２０１）。
　プロセスフローデータ更新要求入力画面を受信すると、クライアント１０は、自己が備える表示部の表示画面にプロセスフローデータ更新要求入力画面を表示する（ステップＳ３０２）。
　図６は、プロセスフローデータ更新要求入力画面の例を示す説明図である。図６に示すように、プロセスフローデータ更新要求入力画面には、更新対象の識別情報（本例においては、プロセスフローデータの主キー部に対応するデータ。すなわち、プロセスフロー番号とプロセスフロー明細番号。）の入力を受け付ける主キーデータ入力領域１１と、ユーザＡによるプロセスデータが示す業務プロセスの種類の入力を受け付ける業務プロセス入力領域１２と、その他のプロセスデータの内容の入力を受け付ける詳細データ入力領域１３と、表示部に出力される表示画面を他の表示画面に切替える要求を受け付ける戻るボタン１４と、各入力領域（本例においては、主キーデータ入力領域１１、業務プロセス入力領域１２、詳細データ入力領域１３。）に入力された内容に基づくプロセスフローデータの更新要求を受け付ける更新ボタン１５とが設けられる。
　クライアント１０は、例えばマウス操作により操作可能なカーソルＰによる各入力領域のうち何れかの選択を受け付けると、選択を受け付けた入力領域に対するテキストデータ（数字と文字とを含む。）の入力の受付を開始する。そして、例えばキーボードによるテキストデータの入力を受け付けると、クライアント１０は、受け付けたテキストデータを選択された領域に表示する。また、クライアント１０は、業務プロセス入力領域１２の選択を受け付けると、プルダウン形式で、所定の業務プロセス名称を選択可能に表示する。なお、プロセスデータの入力を受け付ける方法はこれに限定されず、例えば、クライアント１０が、所定のデータ形式にまとめられた複数のプロセスデータを１度に受け付ける構成としてもよい。
　クライアント１０は、例えばマウス操作により更新ボタン１５の選択を受け付けると、各入力領域に入力されたデータにより構成されるプロセスデータによるプロセスフローデータの更新要求を受け付けたものと判定する（ステップＳ３０３）。
　プロセスフローデータの更新要求（更新要求）を受け付けたものと判定すると、クライアント１０は、受け付けた更新要求を基幹業務サーバ２００に送信する（ステップＳ３０４）。
　更新要求を受信すると、基幹業務サーバ２００は、プロセスフローテーブルＰＴに登録されたプロセスフローデータのうち、受信した更新要求に応じたプロセスフローデータを取得する（ステップＳ２０２）。なお、このとき基幹業務サーバ２００は、更新要求が示す主キーデータ（すなわち、主キーデータ入力領域１１に入力されたデータ）を含むプロセスフローデータを、更新要求（すなわち、受信したプロセスデータ）に応じたプロセスフローデータとして取得する。また、ここでの「取得」とは、後述する処理においてプロセスフローデータと更新条件データとを比較等するために一時的に所定の記憶領域に記憶するという意味である。
　更新要求に応じたプロセスフローデータを取得すると、基幹業務サーバ２００は、更新要求に応じた更新条件データを取得する（ステップＳ２０３）。ここで、更新要求に応じた更新条件データとは、更新要求が示す業務プロセスとプロセスフローデータのタイプ（すなわち、業務プロセス入力領域１２に入力された業務プロセスと、ステップＳ２０２の処理にて取得したプロセスフローデータが示すタイプ）とにより特定可能な更新条件データを意味する（図３参照）。
　更新条件データを取得すると、基幹業務サーバ２００は、取得したプロセスフローデータと更新条件データとを比較し（ステップＳ２０４）、プロセスフローデータの更新条件が満たされているか否か判定する（ステップＳ２０５）。
　ここで、更新条件データにおいて「１」が設定された項目の何れか１つ以上がプロセスフローデータのステータス部において「１」に設定されていないことにより、プロセスフローデータの更新条件が満たされていないと判定すると（ステップＳ２０５のＮ）、基幹業務サーバ２００は、更新エラー通知を作成してクライアント１０に送信し（ステップＳ２０６）、ここでの処理を終了する。
　更新エラー通知を受信すると（ステップＳ３０５のＹ）、クライアント１０は、受信した更新エラー通知に基づいて、自己が備える表示部の表示画面に更新エラー通知表示画面を表示する（ステップＳ３０６）。
　図７は、更新エラー通知表示画面の例を示す説明図である。図７に示すように、更新エラー通知表示画面には、プロセスフローデータ更新要求入力画面に重畳して表示される更新エラー通知表示領域２１が設けられる。ここで、本例における更新エラー通知表示領域２１には、更新エラーをユーザＡに報知するための定型文の他、更新条件の詳細を表示する旨の要求を受け付けるための詳細表示ボタン２２と、更新エラー通知表示領域２１を表示画面から消去する旨の要求を受け付ける閉じるボタン２３とが設けられる。
　クライアント１０は、ユーザＡによる詳細表示ボタン２２の選択を受け付けたことに応じて、例えば、基幹業務サーバ２００におけるプロセスフローデータと更新条件データとの比較結果をユーザＡが認識可能な形態（例えば、プロセスフローデータのステータス部と更新条件データのプロセスフローデータ更新条件とを示す対照表。）で表示する。
　一方、更新条件データにおいて「１」が設定された項目の全てが、プロセスフローデータのステータス部において「１」に設定されていることによりプロセスフローデータの更新条件が満たされていると判定すると（ステップＳ２０５のＹ）、基幹業務サーバ２００は、更新要求が示すプロセスデータをプロセスフローデータに追加してプロセスフローデータを更新する（ステップＳ２０７）。
　プロセスフローデータを更新すると、基幹業務サーバ２００は、更新したプロセスフローデータをクライアント１０に送信して（ステップＳ２０８）、ここでの処理を終了する。
　一方、プロセスフローデータを受信すると、クライアント１０は、受信したプロセスフローデータに基づいて、自己が備える表示部の表示画面に帳票表示画面を表示する（ステップＳ３０７）。
　図８は、帳票表示画面の例を示す説明図である。図８に示すように、帳票表示画面には、プロセスフローデータに基づいた帳票を表示する帳票表示領域３１と、帳票ステータス表示領域３２と、戻るボタン３３と、変更ボタン３４とが設けられる。なお、クライアント１０は、例えばクライアント１０に備えられたキーボードなどの操作に応じて帳票表示領域３１に表示される帳票の縮尺を変更する。
　ここで、帳票表示領域３１には、所定の表示形態でプロセスフローデータの一部または全部が表示される。なお、本例においては、所定の表示形態でプロセスフローデータの一部または全部を表示するための情報が、基幹業務サーバ２００により作成されて、例えば帳票出力処理におけるステップＳ２０８のタイミングで、クライアント１０に送信されるものとする。なお、クライアント１０が、自己が備える記憶装置に記憶された情報に基づいて、受信したプロセスフローデータの一部または全部を所定の表示形態で帳票表示領域３１に表示する構成としてもよい。
　また、帳票ステータス表示領域３２は、帳票表示領域３１に表示される帳票の種類（または、状況。以下、ステータスという。）を表示する領域である。なお、帳票のステータスとしては、例えば、受注伝票、出庫伝票、検収伝票、および請求書など、種々のものが考えられる。
　また、戻るボタン３３は、表示画面をプロセスフローデータ更新要求入力画面に戻す旨の要求を受け付けるためのボタンである。なお、クライアント１０が、ユーザＡによる戻るボタン３３の選択を受け付けたことに応じて、表示画面をプロセスフローデータ更新要求入力画面に戻すだけでなく、基幹業務サーバ２００に対して、更新要求に基づくプロセスフローデータの更新を取り消す旨の要求を送信する構成としてもよい。この場合、クライアント１０は、戻すボタン３３の選択に応じて、各入力領域（本例においては、主キーデータ入力領域１１、業務プロセス入力領域１２、詳細データ入力領域１３。）に入力されていたテキストデータ（業務プロセス入力領域１２においては、選択されていた業務プロセス）を示す状態でプロセスフローデータ更新要求入力画面を表示する構成とされていてもよい。このような構成とすることにより、ユーザＡによる入力内容の確認を容易にすることができるようになる。
　また、変更ボタン３４は、帳票表示領域３１の表示内容を変更する旨の要求を受け付けるためのボタンである。以下、帳票表示領域３１の表示内容の変更処理に関して説明する。
　帳票表示画面を表示すると、クライアント１０は、ユーザＡによる帳票ステータス変更要求を受け付けたか否かを判定する（ステップＳ３０８）。
　本例においては、クライアント１０は、先ず、ユーザＡによる帳票ステータス表示領域３２の選択を受け付ける。そして、例えばマウス操作により操作可能なカーソルＰによる帳票ステータス表示領域３２の選択を受け付けると、クライアント１０は、表示可能な帳票の形態を示す帳票ステータス名称のリストを、例えばプルダウン形式で選択可能に表示する。
　なお、ここで表示する帳票ステータス名称については、基幹業務サーバ２００からプロセスフローデータと共に受信しているものとする。具体的には、基幹業務サーバ２００は、予め所定の記憶領域に記憶された帳票の形態に関するデータ（帳票形態データ）とプロセスフローデータの状態（すなわち、プロセスフローテーブルＰＴの各列項目の入力状態）とに基づいて、表示可能な帳票の形態を示す帳票ステータス名称を特定する。すなわち、例えばクライアント１０に送信するプロセスフローデータのタイプが「在庫売上」であり、プロセス固有データ部に業務プロセス「受注」に関するプロセスデータしか登録されていない場合には、基幹業務サーバ２００は、帳票ステータス名称として「受注伝票」のみを特定する。また、業務プロセス「受注」に関するプロセスデータの他、業務プロセス「出庫」に関するプロセスデータが登録されている場合、基幹業務サーバ２００は、帳票ステータス名称として、「受注伝票」と「出庫伝票」とを特定する。
　図９は、プロセスフローデータの状態に基づく帳票ステータスの遷移について説明するための説明図である。図９において、画像１０１～１０４が、それぞれプロセスフローデータに基づいて帳票表示領域３１に表示され得る帳票（具体的には、伝票）の形態であるとする。なお、画像１０１～１０４は、帳票ステータスの遷移について説明するための説明図であり、各種帳票としての役割を果たすための具体的記載例を示すものではない。
　ここで、画像１０４を例にして説明すると、画像１０４における領域１１１が帳票ステータス名称を、領域１１２がプロセスフローのタイプを、領域１１３がプロセスフローデータに含まれるプロセスデータの業務プロセスの名称をそれぞれ示す領域（本例においては、文字列表示領域）であるものとする。なお、本例においては、プロセスフローデータに含まれるプロセスデータの種類に対応した帳票ステータス名称を領域１１１に表示している。
　この場合、図９における画像１０１から画像１０４への遷移が示すように、１つのプロセスフローデータに対して各業務プロセスに応じたプロセスデータが登録されていく度に、帳票ステータス名称（すなわち、プロセスフローデータに基づいて表示可能な帳票の形態）の種類が増えていくことになる。これは、「次の種類の帳票があるかないか」ではなく、「プロセスフローデータの状態に応じて帳票のステータスが上がっていく（すなわち、表示可能な帳票の種類が増えていく）」ことを意味する。
　以下、帳票出力処理におけるステップＳ３０７の処理の前に、クライアント１０が、業務プロセス「受注」，「出荷指示」，「出庫」，「出庫検収」を含むプロセスフローデータを受信した場合を例にして説明を続ける。なお、本例においては、ステップＳ３０７の処理にて、クライアント１０が、受信したプロセスフローデータが示すプロセスフローにおいて業務プロセス「受注」，「出荷指示」，「出庫」，「出庫検収」のうち最も上位に位置する業務プロセス「受注」に対応する帳票ステータス名称「受注伝票」に対応する帳票を、帳票表示領域３１に表示していたものとする（図８参照）。なお、クライアント１０は、ステップＳ２０７の処理にて新たにプロセスフローデータに追加されたプロセスデータに応じた業務プロセスに対応する帳票を帳票表示領域３１に表示する構成とされていてもよい。
　帳票ステータス変更要求の受付判定処理（ステップＳ３０８）において、ユーザＡによる帳票ステータス変更要求を受け付けていないと判定すると（ステップＳ３０８のＮ）、クライアント１０は、後述するステップＳ３１０の処理に移行する。
　一方、ユーザＡによる帳票ステータス変更要求を受け付けたと判定すると（ステップＳ３０８のＹ）、クライアント１０は、帳票表示領域３１に、受け付けた変更要求に応じた帳票を表示する（ステップＳ３０９）。本例においては、クライアント１０が、ユーザＡによる業務プロセス「出庫」に対応する帳票ステータス名称「出庫伝票」の選択を受け付けて、業務プロセス「出庫」に対応する帳票（出庫伝票）を帳票表示領域３１に表示するものとする。なお、この場合、クライアント１０は、帳票ステータス表示領域３２に、帳票ステータス名称「出庫伝票」を表示する。
　帳票ステータス変更要求に応じた帳票を表示すると、クライアント１０は、帳票出力処理を終了するか否かを判定する（ステップＳ３１０）。ここで、帳票出力処理を終了しないと判定すると（ステップＳ３１０のＮ）、クライアント１０は、ステップＳ３０８の処理に移行する。
　一方、例えばユーザＡによる所定の終了操作を受け付けたことにより帳票出力処理を終了するものと判定すると（ステップＳ３１０のＹ）、クライアント１０は、ここでの処理を終了する。
　以上に説明したように、上述した実施の形態では、データベース（例えば、プロセスフローＤＢ２２０）が、複数の業務プロセスを含むプロセスフロー（例えば、タイプ「在庫売上」のプロセスフロー）に関する各種データを含むプロセスフローデータが登録されるプロセスフローテーブルＰＴと、プロセスフローデータの更新条件を示す更新条件データが登録される更新条件テーブルＵＴとを備え、プロセスフローデータが、ステータスデータと、共通データと、プロセス固有データとを含み、ステータスデータが、プロセスフローに含まれる複数の業務プロセス（例えば、受注、出荷指示、出庫、出庫検収、売上）それぞれの進捗状況を示すデータであり、共通データが、同一のプロセスフローに含まれる業務プロセス間で共通するデータ（例えば、受注先や金額などを示すデータ）であり、プロセス固有データが、同一のプロセスフローに含まれる各業務プロセスに固有のデータ（例えば、受注日や受注テキスト）であり、ステータスデータが、プロセス固有データが更新されたことに応じて更新され（例えば、プロセス固有データが追加されたことに応じて、対応するステータスデータが「０」から「１」に変更され）、更新条件データは、ステータスデータの状態を示すデータである構成としているので、ＥＲＰシステムにおけるデータの更新や検索に要する処理負荷を軽減させることができるようになる。
　すなわち、データ更新時に発生するＩ／Ｏデータ（入出力データ）の量を少なくすることができるようになる。
　図１０は、上述した基幹業務サーバ２００が実行するデータベース更新処理の有用性について説明するための説明図である。
　図１０（Ａ）は、最初のプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。ここで、最初に入力するプロセスデータの種類（すなわち、業務プロセスの種類）は特に限定されない。また、「従来型」とは、図１２に示したように、各業務プロセス毎にテーブルを備えたデータベースを意味する。また、「データ量の差」とは、厳密な数値を示すものではなく、従来型テーブルに格納されたデータを更新する場合と新規型プロセスフローテーブル（すなわち、プロセスフローテーブルＰＴ、図２参照。以下、従来型と比較する場合には適宜「新規型」と呼ぶ。）に格納されたデータを更新する場合とを比較した場合に、新規型の方が扱うデータ量が多くなる場合を＋（プラス）、新規型の方が扱うデータ量が少なくなる場合を－（マイナス）、新規型と従来型とで扱うデータ量が同じとみなせる場合を「０」とする。
　この場合、最初のプロセスデータの入力時においては、ステータス部の更新が必要である分だけ新規型のほうが扱うデータ量が多くなる。ただし、ステータス部のデータ量は小さいので、実質的には従来型と新規型とで、Ｉ／Ｏデータ（入力データと出力データ）の量に大きな差はないといえる。
　一方、図１０（Ｂ）は、２つ目のプロセス以降のプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。すなわち、例えば、主キー部、参照キー部、タイプ部、ステータス部、共通データ部、およびプロセス固有データ部の一部（例えば、業務プロセス「受注」に応じたプロセス固有データ「受信日」，「受注テキスト」）がプロセスフローテーブルＰＴに入力済みのプロセスフローに含まれる業務プロセスに応じたプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。なお、「従来型」は、入力済みのプロセスデータとの対応関係を定義するために、例えば受注テーブルに登録されたプロセスデータ（受注データ）に対応する他のプロセスデータ（例えば、業務プロセス「出荷指示」に対応するプロセスデータ（出荷指示データ））を入力する場合には、出荷指示データとして、本例における主キー部、参照キー部、タイプ部、共通データ部、およびプロセス固有データ部に対応するデータ（図２と図１２参照）の他、対応する受注データを示す「受注番号」と「受注明細」とを入力する必要がある。
　この場合、２つ目のプロセス以降のプロセスデータの入力時においては、ステータス部以外の全ての部分を必要とする従来型に比べて、新規型は、ステータス部とプロセス固有データ部のみを更新するので、Ｉ／Ｏデータの量が少なくなる。
　よって、新規型の方が従来型よりもＩ／Ｏデータの量が少なくなり、システムのパフォーマンス上、有利となる。
　すなわち、データベースのＩ／Ｏが削減することができるようになるため、書き込み量の減少、データベース全体の容量の縮減、およびデータの検索処理に要する処理負荷の軽減を実現することができるようになる。なお、検索処理に要する処理負荷の軽減に関しては、プロセス（プロセスデータ）が複数のテーブルにまたがっていないことも１つの要因となる。
　また、新規型では、プレセスデータの入力順序をある程度、順不同にできるというメリットがある。すなわち、例えばタイプ「在庫売上」で考えると、従来型の場合、プロセスフローの順序が、受注、出荷指示、出庫、出庫検収、売上の順に限定され、順序を変えることができない。これは、従来型のテーブル構造では、業務プロセス間の関係を、後の業務プロセスのデータに前の業務プロセスの主キーを持たせることで表現しているためである（例えば、出荷指示テーブルにおける「受注番号」と「受注明細」。図１２参照）。一方、新規型のテーブル構造では、関係する業務プロセスのデータは、同一のエントリ（すなわち、同一テーブルの同一列）に格納される。このため、業務プロセス間の前後関係に制約を持たず、業務プロセスの順序を柔軟に組み替えることができるようになる。すなわち、例えば実際の業務の順序が「出荷指示の後に受注」であった場合に、プロセスデータの入力順序を、実際の業務の順序に沿った形にすることができるようになる。そのため、進捗管理上（言い換えれば、内部統制上）、従来型に対して有利である。なお、具体的には、現在の卸売業界の業務順序が「出荷指示の後に受注」である。
　また、新規型では、更新条件データの内容を、例えばシステムの管理者やユーザにより設定可能な構成とすることにより、不正なプロセスデータの入力を防止することができるようになる。すなわち、更新条件データの設定によりプロセスデータの更新に制限を持たせることができるようになるため、例えば「出庫実績のない売上を計上できてしまう」など、内部統制上で問題のある順序に制限を設けることができるようになり、データベースに対する信頼性を向上させることができるようになる。
　また、新規型では、プロセスフローの進捗の照会に要する負荷を軽減させることができるようになる。すなわち、プロセスフローがどこまで進んでいるか確認する場合、従来型のテーブル構造では、開始伝票のテーブルから順に、最終伝票のテーブルまでのすべてのテーブルの登録状況を確認する必要がある。例えば、タイプ「在庫売上」を例に考えると、受注、出荷指示、出庫、出庫検収、請求の５つのテーブルを確認する必要がある。一方、新規型のテーブル構造では、プロセスフローの進捗状況を「ステータス部」として持っているため、１つのテーブル、１つのエントリを照会するだけで進捗の確認ができるようになる。これは、進捗状況の照会画面を使用もしくは開発する際に、有利である。
　また、上述した実施の形態では、データベース（例えば、プロセスフローＤＢ２２０）が、プロセスフロー毎に発生するプロセスフローデータを管理するプロセスフローデータ管理サーバ（例えば、基幹業務サーバ２００）に備えられ、プロセスフローデータ管理サーバが、クライアント端末（例えば、クライアント１０，２０）からの要求に応じて、プロセスフローデータの一部又は全部をクライアント端末に提供する構成としているので、業務フローに関するデータ（例えば、帳票の作成に必要な帳票情報を示すプロセスフローデータ）の提供に要する処理負荷が従来に比べて軽減されたシステムを構築することができるようになる。
　また、上述した実施の形態では、プロセスフローデータ管理サーバ（例えば、基幹業務管理サーバ２００）が、複数の業務プロセスそれぞれに関するデータであるプロセスデータの入力を受け付け、更新条件データに基づいて、受け付けたプロセスデータ（例えば、プロセスフローデータの更新要求が示すプロセスデータ）をプロセスフローデータの一部として登録するか判定し（例えば、プロセスフローデータが更新条件を満たしているか否かの判定。図４のステップＳ１０６、図５のステップＳ２０５参照。）、プロセスデータを登録するものと判定したことに応じて、プロセスフローテーブルＰＴに登録されたプロセスフローデータを更新する構成としているので、不正なデータの登録を防止することができるようになる。すなわち、例えばデータ管理の都合上、業務プロセスの一種である「出庫検収」を必ず業務プロセス「受注」、「出荷指示」、「出庫」に関するデータが登録された後にしか登録できないようにすることをユーザが望む場合に、更新条件データを設定するだけで、ユーザが望むようにプロセスフローデータの更新を制限することができるようになる。
　なお、上述した実施の形態では特に言及していないが、プロセスフローデータ管理サーバ（例えば、基幹業務サーバ２００）が、プロセスデータを登録しないと判定したことに応じて、満たされていない更新条件である非充足更新条件を特定し、特定した非充足更新条件をクライアント端末（例えば、クライアント１０，２０）に報知し、所定のタイミングで、非充足更新条件として特定した更新条件が満たされたか判定し、非充足更新条件として特定された更新条件が満たされたと判定したことに応じて、更新条件に対応するプロセスデータをプロセスフローテーブルＰＴに登録する構成としてもよい。
　このような構成とすることにより、クライアント端末のユーザが、同じデータを複数回入力しなければならないということを防止することができるようになる。すなわち、非充足更新条件を報知されたユーザは、非充足条件を満たすための操作を行えば既に入力済みのプロセスデータがプロセスフローテーブルに登録されることとなるので、改めてプロセスフローデータを入力する必要がなくなる。また、プロセスフローデータ管理サーバにとっては、受け付けたプロセスデータに対応するプロセスフローデータの特定や更新条件の充足判定に必要な処理を再度行わずにすむこととなるため、同一処理の実行回数を減らすことができるようになる。
　なお、上述した実施の形態では特に言及していないが、データベース（例えば、プロセスフローＤＢ２２０）が、プロセスフローの進捗状況の判定条件を示すデータである進捗状況判定条件データが登録された進捗状況判定条件テーブルを備え、プロセスフローデータ管理サーバ（例えば、基幹業務サーバ２００）が、進捗状況判定条件に基づいてステータスデータ（例えば、プロセスフローテーブルＰＴにおけるステータス部に格納されたデータ。図２参照。）が進捗状況判定条件を満たしているか判定し、満たしていると判定した進捗状況判定条件に応じた進捗状況をクライアント端末（例えば、クライアント１０，２０）に報知する構成としてもよい。
　図１１は、進捗状況判定条件テーブルに格納された進捗状況判定条件データの格納状態の例を示す説明図である。図１１に示すように、本例における進捗状況判定条件データは、プロセスフローのタイプと、プロセスフローのタイプに応じた進捗状況判定条件とを含む。
　ここで、プロセスフローのタイプには、上述した在庫売上の他、サンプル出荷、サービス売上、名義変更（売上）、名義変更（出荷）、売上返品（元取引参照あり）、売上返品（元取引参照なし）、売上金額調整（プラス）、売上金額調整（マイナス）など、業務プロセスの異なる種々のものが考えられる。
　また、「進捗状況判定条件」とは、プロセスフローの進捗状況の判定基準を示すものであり、本例においては、プロセスフローのタイプ毎に必要な業務プロセス（例えば、受注、出荷指示、出庫、出庫検収、および売上のうち予めタイプ別に設定された業務プロセス）に「１」が設定されているものとする。
　基幹業務サーバ２００は、プロセスフローテーブルＰＴに格納されたプロセスフローデータのうち、ステータス部の状態が進捗状況判定条件データと一致した場合に、プロセスフローデータのエントリが「完了」の状態にあると判定し（すなわち、プロセスフローデータが示すプロセスフローが完了したと判定し）、その旨を所定のクライアント（例えば、クライアント１０，２０）に報知するための処理（報知処理）を行う。
　このような構成とすることにより、業務遂行状況の判定が可能なシステムを構築することができるようになる。特に、プロセスフローデータが含むステータスデータと進捗状況判定条件データとを比較するだけで業務遂行状況の判定処理が可能となるため、複数のテーブルに格納されたデータの入力状況を参照する必要がある従来のものと比べて、業務遂行状況の判定に要する処理負荷を軽減させることができる。
　なお、進捗状況の判定処理または報知処理の開始時機は、クライアント端末からの要求があったときであってもよいし、予め設定された時機であってもよい。
　また、上述した進捗状況判定条件テーブルの例では、進捗状況判定条件データが、プロセスフローが完了したか判定するための完了条件を含む構成としているので、一連の業務の完了判定が容易に可能なシステムを構築することができるようになる。
　なお、進捗状況判定条件データは、プロセスフローが「完了」の状態にあると判定するためのものに限定されず、例えば、「５０％完了」の状態にあると判定するためのデータが含まれる構成としてもよい。また、進捗状況判定条件データが、最初のプロセスデータの入力時から所定時間が経過するまでに入力されるべきであるプロセスデータの種類を示す構成としてもよい。
　また、進捗状況判定条件テーブルに、上述したような「入力されるべきデータが全て入力されたか」の判定機能だけでなく、「入力されるべきではないデータが入力されないよう」にデータの入力を制限する機能を持たせる構成としてもよい。この場合、例えば、基幹業務サーバ２００が、プロセスフローテーブルＰＴを更新するときに、追加するプロセスデータがプロセス固有データである場合に、追加するプロセス固有データの種類と進捗状況判定条件テーブルとを比較して、追加するプロセス固有データの種類が進捗状況条件テーブルに「１」が設定されていない業務プロセスに対応するものである場合にはプロセスフローテーブルの更新をしない構成とすればよい。
　なお、上述した実施の形態では特に言及していないが、データベース（例えば、プロセスフローＤＢ２２０）が、所定のデータが入力されたことに応じて、プロセスフローテーブルＰＴに登録済みのデータのうち少なくとも一部に、データ内容の変更に関する制限を設ける構成としてもよい。
　すなわち、例えば、プロセスフローＤＢ２２０が備えるプロセスフローテーブルＰＴにプロセス「出庫検収」に関するプロセス固有データが登録される前では、プロセスフローテーブルＰＴにおける共通データ部の変更（例えば、データの削除や上書き）が可能であるが、プロセスフローテーブルＰＴにプロセス「出庫検収」に関するプロセス固有データが登録された後では、共通データ部の変更が自由にできないようになる構成としてもよい。この場合、例えば、ユーザが共通データ部の内容を変更する場合に入力すべきパスワードや満たすべき条件などの制限を加える構成とすればよい。このような構成とすることにより、一部のデータの変更に伴うデータ全体における矛盾の発生（すなわち、入力済みのデータの修正に伴う関連データの整合性の欠落）を防止することができるようになる。
　本発明によれば、データの更新や検索に要する処理負荷を軽減させたＥＲＰシステムを構築するのに有用である。
　ＰＴ　　　　　　　プロセスフローテーブル
　ＵＴ　　　　　　　更新条件テーブル
　１０　　　　　　　クライアント
　２０　　　　　　　クライアント
　５１　　　　　　　専用回線
　５２　　　　　　　ＬＡＮ
　５３　　　　　　　インターネット
　２００　　　　　　基幹業務サーバ
　２１０　　　　　　業務アプリケーションプログラムＤＢ
　２２０　　　　　　プロセスフローＤＢ
　２３０　　　　　　その他ＤＢ
　３００　　　　　　ＤＷＨサーバ
　５００　　　　　　統合基幹業務システム

Claims (6)

  1. 　複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータが登録されるプロセスフローテーブルと、
    　前記プロセスフローデータの更新条件を示す更新条件データが登録される更新条件テーブルとを備え、
    　前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、
    　前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、
    　前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、
    　前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、
    　前記ステータスデータは、前記プロセス固有データが更新されたことに応じて更新され、
    　前記更新条件データは、前記ステータスデータの状態を示すデータである
    　ことを特徴とするデータベース。
  2. 　前記プロセスフロー毎に発生するプロセスフローデータを管理するプロセスフローデータ管理サーバに備えられ、
    　該プロセスフローデータ管理サーバは、クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段を含む
    　請求項1記載のデータベース。
  3. 　前記プロセスフローデータ管理サーバは、
    　前記複数の業務プロセスそれぞれに関するデータであるプロセスデータの入力を受け付けるプロセスデータ受付手段と、
    　前記更新条件データに基づいて、前記プロセスデータ受付手段により受け付けられたプロセスデータを前記プロセスフローデータの一部として登録するか判定する登録判定手段と、
    　該登録判定手段により前記プロセスデータを登録するものと判定されたことに応じて、前記プロセスフローテーブルに登録されたプロセスフローデータを更新するプロセスフローデータ更新手段とを含む
    　請求項２記載のデータベース。
  4. 　前記プロセスフローデータ管理サーバは、
    　前記登録判定手段により前記プロセスデータを登録しないと判定されたことに応じて、満たされていない更新条件である非充足更新条件を特定する非充足更新条件特定手段と、
    　該非充足更新条件特定手段により特定された非充足更新条件を前記クライアント端末に報知する報知手段と、
    　所定のタイミングで、前記非充足更新条件として特定された更新条件が満たされたか判定する充足判定手段とを含み、
    　前記プロセスフローデータ更新手段は、前記充足判定手段により前記非充足更新条件として特定された更新条件が満たされたと判定されたことに応じて、当該更新条件に対応するプロセスデータを前記プロセスフローテーブルに登録する
    　請求項３記載のデータベース。
  5. 　クライアント端末に対して各種データを提供するデータ管理サーバであって、
    　複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータと、該プロセスフローデータの更新条件を示す更新条件データとを記憶するプロセスフローデータ記憶手段と、
    　前記プロセスフローの進捗状況に応じて当該プロセスフローデータを更新するプロセスフローデータ更新手段と、
    　前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供手段とを含み、
    　前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、
    　前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、
    　前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、
    　前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、
    　前記更新条件データは、前記ステータスデータの状態を示すデータであり、
    　前記プロセスフローデータ更新手段は、前記更新条件データに基づいて前記プロセスフローデータを更新する
    　ことを特徴とするデータ管理サーバ。
  6. 　クライアント端末に対して各種データを提供するようにデータ管理サーバに動作制御させるためのデータ管理プログラムであって、
    　前記データ管理サーバに、
    　複数の業務プロセスを含むプロセスフローの進捗状況に応じて前記プロセスフローに関する各種データを含むプロセスフローデータと該プロセスフローデータの更新条件を示す更新条件データとを記憶するプロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新するプロセスフローデータ更新処理と、
    　前記クライアント端末からの要求に応じて、前記プロセスフローデータの一部又は全部を当該クライアント端末に提供するプロセスフローデータ提供処理とを実行させ、
    　前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、
    　前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、
    　前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、
    　前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、
    　前記更新条件データは、前記ステータスデータの状態を示すデータであり、
    　前記プロセスフローデータ更新処理にて、前記更新条件データに基づいて前記プロセスフローデータを更新する処理を
    　実行させるためのデータ管理プログラム。
PCT/JP2011/002352 2010-12-21 2011-04-22 データベース、データ管理サーバ、およびデータ管理プログラム WO2012086097A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP11850457.0A EP2527994A4 (en) 2010-12-21 2011-04-22 DATABASE, DATA MANAGEMENT SERVER AND DATA MANAGEMENT PROGRAM
JP2012529059A JP5386639B2 (ja) 2010-12-21 2011-04-22 データベース、データ管理サーバ、およびデータ管理プログラム
CN2011800154165A CN102812462A (zh) 2010-12-21 2011-04-22 数据库，数据管理服务器和数据管理程序
US13/574,384 US8812471B2 (en) 2010-12-21 2011-04-22 Database, process flow data management server, and process flow data managing program product

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010-284507 2010-12-21
JP2010284507 2010-12-21

Publications (1)

Publication Number Publication Date
WO2012086097A1 true WO2012086097A1 (ja) 2012-06-28

Family

ID=46313393

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/002352 WO2012086097A1 (ja) 2010-12-21 2011-04-22 データベース、データ管理サーバ、およびデータ管理プログラム

Country Status (5)

Country Link
US (1) US8812471B2 (ja)
EP (1) EP2527994A4 (ja)
JP (1) JP5386639B2 (ja)
CN (1) CN102812462A (ja)
WO (1) WO2012086097A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7484466B2 (ja) 2020-06-12 2024-05-16 株式会社リコー 情報処理装置、情報処理方法、プログラム及び情報処理システム

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021099839A1 (en) 2019-11-18 2021-05-27 Roy Mann Collaborative networking systems, methods, and devices
WO2021144656A1 (en) 2020-01-15 2021-07-22 Monday.Com Digital processing systems and methods for graphical dynamic table gauges in collaborative work systems
US11410129B2 (en) 2010-05-01 2022-08-09 Monday.com Ltd. Digital processing systems and methods for two-way syncing with third party applications in collaborative work systems
WO2021161104A1 (en) 2020-02-12 2021-08-19 Monday.Com Enhanced display features in collaborative network systems, methods, and devices
JP6351413B2 (ja) * 2014-07-15 2018-07-04 キヤノン株式会社 画像形成装置およびその制御方法、並びにプログラム
JP2016076163A (ja) * 2014-10-08 2016-05-12 株式会社アイ・ピー・エス 連携サーバ、連携プログラム、およびｅｃシステム
CN105843961B (zh) * 2016-04-18 2018-12-14 中邮建技术有限公司 一种流程与后台数据分离的信息化系统数据库架构方法
CN106803152A (zh) * 2017-01-23 2017-06-06 北京外企德科人力资源服务上海有限公司 一种业务流程可视化监控系统
US11698890B2 (en) 2018-07-04 2023-07-11 Monday.com Ltd. System and method for generating a column-oriented data structure repository for columns of single data types
US11436359B2 (en) 2018-07-04 2022-09-06 Monday.com Ltd. System and method for managing permissions of users for a single data type column-oriented data structure
US11361156B2 (en) 2019-11-18 2022-06-14 Monday.Com Digital processing systems and methods for real-time status aggregation in collaborative work systems
EP4143732A1 (en) 2020-05-01 2023-03-08 Monday.com Ltd. Digital processing systems and methods for enhanced collaborative workflow and networking systems, methods, and devices
US20240184989A1 (en) 2020-05-01 2024-06-06 Monday.com Ltd. Digital processing systems and methods for virtualfile-based electronic white board in collaborative work systems systems
US11277361B2 (en) 2020-05-03 2022-03-15 Monday.com Ltd. Digital processing systems and methods for variable hang-time for social layer messages in collaborative work systems
US11531452B2 (en) 2021-01-14 2022-12-20 Monday.com Ltd. Digital processing systems and methods for group-based document edit tracking in collaborative work systems
US12056664B2 (en) 2021-08-17 2024-08-06 Monday.com Ltd. Digital processing systems and methods for external events trigger automatic text-based document alterations in collaborative work systems
US12105948B2 (en) 2021-10-29 2024-10-01 Monday.com Ltd. Digital processing systems and methods for display navigation mini maps
US11741071B1 (en) 2022-12-28 2023-08-29 Monday.com Ltd. Digital processing systems and methods for navigating and viewing displayed content
US11886683B1 (en) 2022-12-30 2024-01-30 Monday.com Ltd Digital processing systems and methods for presenting board graphics
US11893381B1 (en) 2023-02-21 2024-02-06 Monday.com Ltd Digital processing systems and methods for reducing file bundle sizes
US12056255B1 (en) 2023-11-28 2024-08-06 Monday.com Ltd. Digital processing systems and methods for facilitating the development and implementation of applications in conjunction with a serverless environment

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08203794A (ja) * 1995-01-23 1996-08-09 Nippondenso Co Ltd 製造プロセス生成システム
JPH10214113A (ja) * 1996-05-15 1998-08-11 Hitachi Ltd 掲示板型データベースを用いた業務処理システム及びその処理方法
JP2003296560A (ja) * 2002-04-03 2003-10-17 Aisin Aw Co Ltd 電子承認ワークフローシステム及び記憶媒体
JP2009099070A (ja) 2007-10-18 2009-05-07 Sunallomer Ltd データ変換装置及びデータ変換方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6275809B1 (en) 1996-05-15 2001-08-14 Hitachi, Ltd. Business processing system employing a notice board business system database and method of processing the same
JP2002312208A (ja) 2001-04-11 2002-10-25 Mitsubishi Electric Corp データウェアハウスシステム
JP2003323582A (ja) 2002-04-30 2003-11-14 Nec System Technologies Ltd 携帯電話を使用した電子帳票システム
JP2007200136A (ja) 2006-01-27 2007-08-09 Fuji Xerox Co Ltd 業務支援システム、業務支援プログラムおよび業務支援方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08203794A (ja) * 1995-01-23 1996-08-09 Nippondenso Co Ltd 製造プロセス生成システム
JPH10214113A (ja) * 1996-05-15 1998-08-11 Hitachi Ltd 掲示板型データベースを用いた業務処理システム及びその処理方法
JP2003296560A (ja) * 2002-04-03 2003-10-17 Aisin Aw Co Ltd 電子承認ワークフローシステム及び記憶媒体
JP2009099070A (ja) 2007-10-18 2009-05-07 Sunallomer Ltd データ変換装置及びデータ変換方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2527994A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7484466B2 (ja) 2020-06-12 2024-05-16 株式会社リコー 情報処理装置、情報処理方法、プログラム及び情報処理システム

Also Published As

Publication number Publication date
JPWO2012086097A1 (ja) 2014-05-22
US20130006917A1 (en) 2013-01-03
CN102812462A (zh) 2012-12-05
EP2527994A4 (en) 2013-10-02
EP2527994A1 (en) 2012-11-28
JP5386639B2 (ja) 2014-01-15
US8812471B2 (en) 2014-08-19

Similar Documents

Publication Publication Date Title
JP5386639B2 (ja) データベース、データ管理サーバ、およびデータ管理プログラム
JP5502251B1 (ja) 帳票データ管理サーバ、および帳票データ管理プログラム
US20150081365A1 (en) Mobile terminal management server and mobile terminal management program
JP2007188442A (ja) 販売管理装置、方法及びコンピュータプログラム
JP5237460B2 (ja) データベース、管理サーバ、および管理プログラム
WO2015198365A1 (ja) 連携サーバ、連携プログラム、およびｅｃシステム
US20150120356A1 (en) Mobile terminal management server and mobile terminal management program
JP5451885B2 (ja) データベース、データ管理サーバ、およびデータ管理プログラム
WO2013114439A1 (ja) 携帯端末管理サーバ、および携帯端末管理プログラム
WO2013114438A1 (ja) 携帯端末管理サーバ、および携帯端末管理プログラム
JP5597769B2 (ja) 携帯端末管理サーバ、および携帯端末管理プログラム
WO2014002138A1 (ja) 携帯端末管理サーバ、および携帯端末管理プログラム
US20160148129A1 (en) Report data management device, non-transitory computer-readable storage medium storing report data management program, and report data management method
US20160104230A1 (en) Cooperation server, non-transitory computer-readable storage medium storing cooperation program, and ec system
WO2015198364A1 (ja) 連携サーバ、連携プログラム、およびｅｃシステム
WO2015198362A1 (ja) 連携サーバ、連携プログラム、およびｅｃシステム
JP2007114953A (ja) 情報システム、アクション送信装置およびアクション送信プログラム
WO2015198363A1 (ja) 連携サーバ、連携プログラム、およびｅｃシステム
JPWO2013114439A1 (ja) 携帯端末管理サーバ、および携帯端末管理プログラム
JPWO2013114438A1 (ja) 携帯端末管理サーバ、および携帯端末管理プログラム
JP2019021173A (ja) 情報出力管理装置および情報出力管理方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180015416.5

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2012529059

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 6164/DELNP/2012

Country of ref document: IN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11850457

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011850457

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13574384

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE