JP2007249422A - Organization constitution management system, and program therefor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To substantially automatically change an organization constitution DB in accompaniment to an organization change. <P>SOLUTION: A maintenance tool 31 (or 13) inputs an old post code together with new post information in a manager terminal 30, imports them, while correlated each other, into a post information table of the organization constitution DB 11a, and calls an organization development batch processing part 12. The organization development batch processing part 12 replaces the old post code into a new post code in a business transfer information table and a belonging position information table stored in the organization constitution DB 11a, referring to the post information table. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a method for managing / updating organization configuration information.

  2. Description of the Related Art Conventionally, an organization configuration management system for managing employees or the like in an arbitrary organization (such as a company) using a computer has been built in, for example, a company. In this system, the department name of the company, the business name of each department, and the department name to which each employee belongs are stored in a database.

  When there is an organizational change, it is necessary to change the organizational structure information stored in the above database. However, since this change was done manually, it took time and input errors occurred. It was. Furthermore, in recent years, organizational changes in companies and the like have been carried out relatively frequently, and it is necessary to perform the above-described change work each time, increasing the burden on the operator.

  Further, in reality, only the new department name after the organization change is notified in advance, and the new department of each employee is notified later. In such a case, if only the department information is changed to the new department first because there is not much time before the organization change date, the employee affiliation information remains managed in the old department. This is a problem in system operation.

FIG. 7 is a diagram for explaining a change operation of the organization configuration information when the organization is changed in the conventional organization configuration management system.
The organization configuration DB (database) shown in the figure stores affiliation information, department information, business takeover information, and the like. When there is an organization change, the user activates an arbitrary maintenance tool provided in the information processing terminal operated by the user, accesses the organization configuration DB, and manually changes the various information. That is, when an organizational change occurs, the department information is changed manually. At that time, the department information before the change is not left. In addition, when an employee is changed due to this organizational change, the affiliation information is changed manually. Similarly, since business handover usually takes place with this organizational change, the business handover information is manually changed. These changes were done separately.

  In addition, as the types of maintenance tools, there may be a mix of tools with and without a screen interface that can acquire the values before and after the change. In the latter case, the values before the change Because it was not possible to acquire, organizational change processing could not be implemented internally. An import tool that imports information into the database is an example of the latter, but because data is imported independently for each database table, even if the value before the change is entered for the change in the department code, It is difficult to change the information of other tables using the department code in conjunction with each other, and it is necessary to generate change data individually for each table.

A specific example of organizational change is shown in FIG.
In the illustrated example, Section A and Section B are integrated to newly establish Section C. In section A, there was a manager, “Yamada”, a chief officer, “Sato”, and a regular employee, “Suzuki”. The manager of “Yamada” was also the manager of the B section. In section B, there was a chief “Tanaka” and a regular employee “Watanabe”. These newly established employees in section A and section B will be transferred to section C. That is, in section C, the section manager “Yamada”, the chiefs “Sato” and “Tanaka”, and the regular employees “Suzuki” and “Watanabe” are arranged. In addition, section C takes over work a of section A and work b of section B as it is.

FIG. 9 shows a procedure for changing the data in the organization configuration DB when the organization is changed.
The data changing operation shown in FIG. 9 is performed manually by the user, as described in the following (1) to (7). At that time, data is fetched from the personnel master DB in another system, and the data of the organization configuration DB is changed based on this data.
(1) Information on Section C is additionally created in the department information stored in the organization structure DB.
(2) The affiliation information is changed so that the affiliation of the employee in section A is transferred to section C (deleted from section A).
(3) Change the affiliation information so that the affiliation of the employee in section B is transferred to section C (delete from section B).
(4) The business handover information is changed so that the business a in Section A is handed over to Section C.
(5) The business handover information is changed so that the business b of Section B is handed over to Section C.
(6) Delete department A department information from the DB.
(7) Delete department B department information from the DB.

  For example, Patent Document 1 is known regarding the creation of new organization information data when an organization is changed as described above. Patent Document 1 discloses the creation of a new affiliation file, but this is simply copying the data of the employee master file to the affiliation table, as described in FIG. Only. That is, new department information is already stored in the employee master file, or a new department name is manually input for an employee whose department has been changed after the new department file is created.

  Further, Patent Document 2 has a description of a tissue database. For example, as shown in FIG. 30, the subsequent department name indicates the department name that will take over the work of the current department when there is an organizational change, etc., and the validity period is set for each department. Thus, it is disclosed that, for example, the department “Y department” is merged into the department “W department” with the date “2000.04.01”. Then, the approval system can automatically change the drafting unit signature, the approval route, and the like based on the information of the successor unit signature by referring to the organization database.

Patent Document 2 proposes a business processing system that can flexibly cope with personnel changes and organizational changes.
JP 7-44433 A JP 2002-82836 A JP 2000-250872 A

  In Patent Document 2, as described above, the approval system can automatically change the drafting unit signature, the approval route, and the like based on the information of the successor unit signature by referring to the organization database. However, the data in the organization database (successor department signature, expiration date, etc.) is not automatically changed. The same applies to Patent Document 3. Patent Document 1 is as described above.

  In relational database operations, it is desirable not to change the uniquely managed code system. However, when dealing with organizational information, the department code must be changed due to organizational changes including consolidation of departments. It may be necessary. In addition, employee changes and business takeovers usually occur with organizational changes.

  Conventionally, as described above, it is necessary to manually input new employee affiliation information and business hand-over information. In particular, in an organization in which organizational changes are frequently performed, the work load has increased. Here, the present inventor, even in a situation where organizational changes are frequently performed, even if the organizational change is made, the department name and department code are simply changed, or a plurality of departments are integrated into one. Therefore, we focused on the fact that very few employees are transferred to completely different departments. From this, we thought that the work burden of manual data change work could be reduced by changing most of the employee affiliation information and business hand-over information by automatic processing.

  The problem of the present invention is that most of the affiliation information, business takeover information, etc. are automatically set by simply letting the user set the change contents of the department information in the organization structure DB storage data such as department information, affiliation information, business takeover information. It is an object of the present invention to provide an organization configuration management system, a program, and the like that can be changed by processing, thereby reducing the user's workload and reducing input errors.

  The organization configuration management system of the present invention displays an organization configuration database for storing a department information table, a business takeover information table, and an affiliation information table, and displays a department change screen to input a corresponding old department code together with new department information. A maintenance tool for importing the inputted new department information into the department information table in association with the old department code; and referring to the imported new department information and old department code, the business takeover information table In the department information table, the employee department is changed from the old department to the new department, and the old department information is updated in the department information table. And a tissue expansion processing means to be deleted.

  In the above system, first, when the input new department information is imported into the department information table, the old department code is also stored in association with it. Thus, the relationship between the new and old departments can be understood by referring to the department information table. Thus, the organization development processing means can automatically change the business takeover information table and the affiliation information table to the contents corresponding to the organization change as described above by referring to the department information table. The organizational structure database is automatically updated by the organizational development processing means when there is virtually no change of employees, as in the case of an organizational change such as a simple departmental change, or in the case of simple department integration. Is done. Even if this is not the case, there are often very few employees who move substantially, so it is only necessary to manually correct some of the employees, so it is expected that the burden on the user will be reduced and mistakes will be reduced. it can.

  Further, for example, when a plurality of old departments are integrated into one new department, each of the old departments is sequentially executed by the maintenance tool and correspondingly executed by the organization development processing means. As a result, the department information table, the business takeover information table, and the affiliation information table are changed according to the department integration.

  In addition, for example, when the organization development processing unit determines that the same employee is concurrently serving as the plurality of old departments in the affiliation information table, after canceling the concurrent position, Change the department to the new department to be integrated.

  According to the organization configuration management system of the present invention, its program, etc., the stored data of the organization configuration DB such as department information, affiliation information, business takeover information, etc. Most of the business takeover information and the like can be changed by automatic processing, thereby reducing the work burden on the user and reducing input errors.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a schematic configuration diagram of an organization configuration management system according to the present embodiment.
The illustrated organization configuration management system includes an authentication server 10, a web application server 20, an administrator terminal 30, a general user terminal 40, and the like, which are connected to a network (such as a LAN) (not shown) and transmit / receive data to / from each other. It is possible.

  Since the Web application server 20 and the general user terminal 40 are not directly related to the present invention, description thereof is omitted. Also, the illustrated access authentication module and access control module in the authentication server 10 are not directly related to the present invention and will not be described.

  The authentication server 10 includes a database (DB) 11, an organization development batch processing unit 12, a maintenance tool 13, and a Web server function 14. The database 11 includes two organization configuration DBs 11a and 11b, which are in a relationship between a work and a master, and basically store the same data. When changing the data, first, the data of the workpiece (11a) is changed, and then the change of the workpiece is reflected on the master (11b) side. The organization configuration DBs 11a and 11b store a department information table 50, a business takeover information table 60, an affiliation information table 70, and the like, which will be described later.

  The feature of the present invention is mainly in the tissue development batch processing unit 12 (and also a maintenance tool), which will be described in detail later. Various processing functions of the authentication server 10 and the administrator terminal 30 such as the organization development batch processing unit 12, the maintenance tools 13 and 31, the Web server function 14 and the like are not shown in the authentication server 10 and the administrator terminal 30. The CPU is realized by reading and executing a predetermined application program stored in a storage device (hard disk, memory, etc.) (not shown). In addition, what has the characteristic of the said invention is not restricted to an authentication server, Other arbitrary servers may be sufficient.

  The administrator terminal 30 includes a Web browser 32 so that the maintenance tool 13 can be used via the Web server function 14 of the authentication server 10. Alternatively, the administrator terminal 30 itself may have the maintenance tool 31. The maintenance tool is a tool for allowing an administrator to manage data stored in the database 11 (data addition, change, deletion, etc.), and an input / setting screen (GUI screen) for data management is displayed on the administrator. A function of accepting input by displaying on the display of the terminal 30 and an import function are provided. Furthermore, unlike the prior art, it also has a function for setting the department code before change.

FIG. 2 shows a processing flowchart of the tissue development batch processing unit 12.
Hereinafter, the process illustrated in FIG. 2 will be described with reference to the specific examples illustrated in FIGS. 3 and 4.
The specific examples shown in FIGS. 3 and 4 are the specific examples described with reference to FIG. That is, an example is given in which the A section and the B section are integrated to newly establish a C section, and the operations and employees of the A section and the B section are transferred to the C section as they are.

  Conventionally, the above-described data changing operations (1) to (7) are required. However, according to this method, only the following manual operations (A) and (B) are required. That is, after the work of (A) is executed, the organization expansion batch processing unit 12 is called to execute the process. Similarly, after the operation of (B) is executed, the tissue expansion batch processing unit 12 is called to execute the process. The organization configuration DB 11a is changed in accordance with the integration of the database (of course, thereafter, the organization configuration DB 11b is also updated to have the same contents as the DB 11a). In the following description, the maintenance tool 31 is used, but the maintenance tool 13 may be used.

  (A) The administrator uses the maintenance tool 31 on the administrator terminal 30 to display a GUI screen for setting the department information, so that the department C department information, department code, and department code before change (here, A Enter the department's department code. The maintenance tool 31 imports this setting data into the department information table and turns on the operation flag. Then, the organization expansion batch processing unit 12 is called.

  (B) The administrator uses the maintenance tool 31 on the administrator terminal 30 to display a GUI screen for setting the department information, so that the department C department information, department code, and pre-change department code (in this case B Enter the department's department code. The maintenance tool 31 imports this setting data into the department information table and turns on the operation flag. The organization development batch processing unit 12 is called.

Hereinafter, first, the case (A) will be described.
First, a department information table 50, a business takeover information table 60, and an affiliation information table 70 are stored in the organization structure DB 11a. FIG. 3B shows the state of each table before the change. That is, the department information table 50 includes fields of a department name 52, a department code 51, and a department history number 53, and here, information relating to sections A and B is stored. Further, the department information table 50 also includes fields for an operation flag 54 and a pre-change department code 55, which are different from conventional ones. At times other than the change work, the operation flag 54 is OFF, and the pre-change department code 55 is “no data”.

  The business takeover information table 60 stores the business name 63 of the business in charge of each department and the business code 61 thereof. Here, information on the operations of Section A and Section B is stored. The affiliation information table 70 stores the name 73, personal code (employee number, etc.) 71 of each employee, department code 72 of the department to which the employee belongs, and job title 74. Here, Yamada, Sato, and Suzuki belong to section A, Yamada also serves as the section manager of section B, and Tanaka and Watanabe belong to section B.

  FIG. 3A shows the data input in the above operation (A). That is, “Section C” is input as a new department name, “10010030” is input as the department code, and the department code “10010010” of Section A is input as the department code before change.

  The maintenance tool 31 imports this input data into the department information table 50. At that time, the operation flag 54 is turned ON. As a result, the department information table 50 is in the state shown in FIG. Thereby, it is possible to determine from which department (department code) a certain department has been changed by referring to the department information table 50.

  In this state, by calling the organization development batch processing unit 12 to execute the processing of FIG. 2, the department information table 50, the business takeover information table 60, and the affiliation information table 70 are in the state shown in FIG. Become.

  That is, the organization development batch processing unit 12 first checks the operation flag 54 with reference to the department information table 50, and determines whether there is a record with the flag ON (step S11). If there is no record with the flag ON (step S11, NO), this process ends. If there is a record with the flag ON, the pre-change department code 55 in the record is acquired (step S12), and the pre-change department code acquired by the department code 62 in step S12 in the business takeover information table 60. The department code 62 of all records that are the same as 55 is changed to the department code 51 of the record whose flag is ON (step S13). In the example of FIG. 3D, the department code 62 in the record in the first row of the business takeover information table 60 is changed to “10010030”. As a result, the work of the old department “A section” is transferred to the new department “C section”.

  The operation flag 54 may be omitted. In this case, the determination in step S11 is made based on whether or not there is data in the pre-change department code 55 (as will be described later, this field is cleared when the processing in FIG. Is a newly added record).

  Subsequently, with reference to the affiliation information table 70, it is determined whether or not there is a duplicate row for each record (step S14). If there is a duplicate row (step S14, YES), these contents are the same. Among the plurality of records, the record whose department code 72 is the same as the previous department code 55 is deleted (step S16). As a result, if the same employee is concurrently serving as a plurality of old departments, the concurrent appointment is canceled. On the other hand, when there is no duplicate row (step S14, NO), when the department code 72 of the record to be processed is the same as the department code 55 before change, this is changed to the department code 51 of the record whose flag is ON. (Step S15).

  The above process is repeated until it is executed for all the records in the affiliation information table 70. When the process is executed for all the records (step S17, YES), the process proceeds to step S18.

At this stage, the business takeover information table 60 and the affiliation information table 70 are in a state after change shown in FIG.
Note that whether or not there are duplicate rows is determined by whether or not there are other records having the same personal code 71, department code 72, and name 73. However, the department code 72 is determined to have been changed from the old department code to the new department code for all the corresponding records. That is, in this example, it is determined whether or not there are duplicate lines as if the department codes in the first to third lines of the affiliation information table 70 are all changed to “10010030”. Therefore, in the example shown in FIG. 3B, there is no record with duplicate rows.

  In step S18, the old department information is deleted from the department information table 50. That is, the record whose department code 51 is the same as the previous department code 55 is deleted.

  Finally, the field of the department code 55 before change in the record with the flag ON is cleared and the operation flag 54 is turned OFF (step S19). At that time, the unspecified item (department history number) inherits the old department information (section A information). As a result, the department information table 50 is changed to the state shown in FIG.

  Thus, the change process accompanying the operation (A) is completed, and then the operation (B) is performed to call the tissue expansion batch processing unit 12 again to execute the process of FIG. In this case, as shown in FIG. 4B, the state before the change is the state of FIG.

  FIG. 4A shows the data input by the operation (B). That is, “Section C” is entered as a new department name, “10010030” is entered as the department code, and the department code “10010020” is assigned as the department code before the change. As in the case of the above operation (A), the maintenance tool 31 imports this input data into the department information table 50 (although it has not been explained), the department code 51 and the department name 52 are included in this case. If the same record as the input data already exists in the department information table 50, the input data is overwritten on this record. However, data items that have not been entered (in this example, the department history number) inherit the existing contents. Of course, the operation flag 54 of this record is turned ON. As a result, the department information table 50 is in the state shown in FIG.

  Then, the processing of FIG. 2 is executed, but here, only the differences from the case of the example of FIG. 3 will be described. That is, in the example of FIG. 3, there is no record in which the determination in step S14 is YES, but in this example, there are two records having the same content for the section manager “Yamada”. Therefore, the record whose department code 72 is the same as the department code 55 (10010020) before the change, that is, the record in the fourth line in the figure is deleted from the affiliation information table 70 by the process of step S16. Otherwise, as in the example of FIG. 3, the department codes 62 and 72 in the business takeover information table 60 and the affiliation information table 70 are replaced with the department C department code '10010030'. The record of Section B is deleted, and these various tables are in the state after change shown in FIG.

FIG. 6 shows an example of an organization change setting screen displayed on the display of the administrator terminal 30 by the maintenance tool.
By the processing of FIG. 2 by the organization development batch processing unit 12 described above, in this method, as shown in FIG. 5, the administrator can change the data of the organization configuration DB accompanying the organization change (including the integration of departments). In this case, you can set not only the department information but also the employee change due to the organizational change (change of affiliation information) by setting the department information after the change and the department code before the change using the maintenance tool. In addition, the setting of business takeover (change of business takeover information) accompanying the organization change is automatically performed, and the work load on the administrator is reduced. As shown in FIG. 5, in the case of an employee change or work transfer without an organization change, the administrator manually changes the data in the organization configuration DB as usual.

  However, this does not necessarily complete the data change work of the organizational structure DB. In the above example, all the members of the departments before the change (section A, section B) have been transferred to the post-change department (section C) and the post remains unchanged. DB data modification work is completed, but it is possible that some employees have moved to a completely different department, moved from another department, or changed their job titles. Setting is required. In addition, operations that are transferred to completely different departments also require manual settings.

  However, especially in the case of frequent organizational changes, it is often the case that the department name is simply changed or multiple departments are integrated. In such cases, not all members of the old department may belong. In many cases, the change from the old department to the new department is often performed, and the business is often handed over to the new department as it is. There are not a few cases, and even if not, manual changes can be done for only a few employees, so the workload can be greatly reduced and human error can be reduced.

  In addition, when only the new department name after the organizational change is notified in advance and later the new department of each employee is notified, conventionally, if only the department information is changed to the new department first, the employee Since the affiliation information is still managed by the old department, there was a problem in system operation. However, with this method, as described above, the affiliation information is also changed in a corresponding manner after the organization change. Can solve this problem. The above-mentioned “very few employees” can be corrected manually when the new department of each employee is notified.

FIG. 1 is a schematic configuration diagram of an organization configuration management system according to the present embodiment. It is a process flowchart figure of an organization expansion batch processing part. (A)-(d) is a figure (the 1) which shows the mode of the automatic update of organization structure DB. (A)-(d) is a figure (the 2) which shows the mode of the automatic update of organization structure DB. It is a figure which shows the characteristic of this method roughly. It is an example of a department change setting screen. It is a figure for demonstrating the change operation | work of the organization structure information at the time of the organization change in the conventional organization structure management system. It is a specific example of organizational change. This is a conventional data change work procedure when there is an organizational change.

Explanation of symbols

10 Authentication Server 11 Database 11a Organization Configuration DB (Work)
11b Organizational structure DB (master)
12 Organization Deployment Batch Processing Unit 13 Maintenance Tool 14 Web Server Function 20 Web Application Server 30 Administrator Terminal 31 Maintenance Tool 32 Web Browser 40 General User Terminal 40
50 Department information table 51 Department code 52 Department name 53 Department history number 54 Operation flag 55 Department code before change 60 Business takeover information table 61 Business code 62 Department code 63 Business name 70 Affiliation information table 71 Personal code 71
72 Department Code 73 Name 74 Title

Claims (4)

An organization structure database for storing a department information table, a business takeover information table, and an affiliation information table;
A maintenance tool that displays a department change screen and inputs a corresponding old department code together with new department information, and imports the input new department information in association with the old department code into the department information table;
Referring to the imported new department information and old department code, in the business takeover information table, the data change is made to transfer the business of the old department to the new department, and the department to which each employee belongs in the department information table Organizational development processing means for changing the old department to the new department and deleting the old department information in the department information table;
An organization configuration management system comprising:   When integrating a plurality of old departments into one new department, each of the old departments is sequentially input by the maintenance tool and the corresponding processing by the organization development processing means is executed. 2. The organization configuration management system according to claim 1, wherein data of the department information table, the business takeover information table, and the affiliation information table is changed according to the integration.   When the organization development processing means determines that the same employee is concurrently serving as the plurality of old departments in the affiliation information table, after canceling the concurrent appointment, the department to which the employee belongs is 3. The organization configuration management system according to claim 2, wherein the system is changed to a new department to be integrated. To a computer having an organization configuration database for storing a department information table, a business takeover information table, and an affiliation information table,
A function for displaying a department change screen, inputting an old department code corresponding to the new department information, and importing the inputted new department information in association with the old department code into the department information table;
Referring to the imported new department information and old department code, in the business takeover information table, the data change is made to transfer the business of the old department to the new department, and the department to which each employee belongs in the department information table A function of changing the old department information from the old department to the new department, and deleting the old department information in the department information table,
A program to realize