Administration management system
The administrative management system addresses inefficiencies in workflow management by linking macro-level financial planning with micro-level budget assessments, enabling efficient administrative activities through object-oriented data management and flexible disclosure controls.
Patent Information
- Application Number
- JP2025148824
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-09-09
- Publication Date
- 2025-11-07
AI Technical Summary
Existing administrative management systems fail to efficiently promote administrative activities in organizations by not linking macro-level financial planning with micro-level budget assessments, leading to inefficiencies in workflow management and data access control.
An administrative management system that performs object-oriented workflow management, storing and managing administrative data with defined permissions, assigning issues to specific persons, and allowing flexible disclosure scopes, while associating message threads with issues to enhance communication and workflow progression.
Enables efficient promotion of administrative activities by managing workflows based on issues linked to administrative objects, allowing flexible disclosure adjustments, and enhancing communication within the system.
Smart Images

Figure 2025168574000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to an administrative management system, an administrative management method, and a computer program. [Background technology]
[0002] 2. Description of the Related Art Information processing techniques are known for improving the efficiency of administrative activities in administrative organizations, including local governments.
[0003] Patent Document 1 discloses technology that aims to resolve the problem of local government financial planning being conducted from a macro perspective, while budget assessments for individual administrative projects are conducted from a micro perspective, and that the two are not linked. This technology makes it possible to maintain consistency between individual plans and overall strategies by establishing rules, making the creation of revenue and expenditure plans for individual administrative projects more detailed and computerizing them, and by linking the financial planning of the local government as a whole with the management and evaluation of administrative projects, thereby enabling long-term financial estimates based on project accumulation. [Prior art documents] [Patent documents]
[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2005-293321 Summary of the Invention [Problem to be solved by the invention]
[0005] The prior art has achieved simplification of the processes related to budget assessment and administrative reform planning, but it is unable to efficiently promote administrative activities in administrative organizations.
[0006] In view of the above-mentioned problems, an object of the present invention is to provide a technology for efficiently promoting administrative activities in administrative organizations. [Means for solving the problem]
[0007] [1] An administrative management system that performs object-oriented workflow management, storing administrative data having a plurality of types of data items and registered for each administrative object; An administrative management system that creates issues associated with individual administrative objects based on designated topics and administrative objects, and determines the processing status of a workflow in the topic using the processing status related to the issues. [2] storing an administrative object group that is a set of the administrative data; Accepts the designation of administrative object groups to be included in the workflow and the workflow manager, An administrative management system as described in [1], which creates an issue group, which is a collection of multiple issues corresponding to each of all administrative objects included in a specified administrative object group, based on the specified administrative object group, and assigns multiple issues belonging to the issue group to a person in charge of a specified workflow. [3] Accepts the designation of administrative objects to be included in the workflow and the person in charge of each stage of the workflow. An administrative management system described in [1] or [2], in which an issue associated with a specified administrative object is assigned to a person in charge of each stage, and when a person in charge of a certain stage performs an operation to complete the issue, the workflow proceeds to the next stage. [4] An administrative management system described in any of [1] to [3], in which viewing permissions for at least some of the data items of the administrative data and at least some of the data items of the issues are set to different ranges. [5] A user group includes some or all users belonging to the same department, An administrative management system described in any of [1] to [4], wherein viewing permissions are set on a user group basis for at least some of the data items of the administrative data and / or at least some of the data items of the issues. [6] The administrative data is managed in versions, and viewing permissions are set for at least some data items of the administrative data for each version; One or more message threads are associated with each of the issues; An administrative management system described in any of [1] to [5], in which the version of the administrative data in question is set in the message thread or in the message within the message thread, and viewing rights are set according to the viewing rights for each version of the administrative data. [7] Data items to be input corresponding to the topic are defined; The administrative management system according to any one of [1] to [6], wherein an input field corresponding to the defined data item is linked to the display screen of the issue. [8] One or more message threads are associated with each issue; The administrative management system according to any one of [1] to [7], wherein a mention of a predetermined user or user group can be set in the message thread or a message in the message thread. [9] One or more message threads are associated with each issue; The message thread or a message within the message thread is accompanied by a posting purpose; An administrative management system according to any one of [2] or [3] to [8], which cites [2], that aggregates the issues in the issue group based on any one or more types of posting purposes.
[10] One or more message threads are associated with each issue; A target of the message is added to the message thread or a message within the message thread; The administrative management system according to any one of [1] to [9], wherein the object of the indication includes a data item or an attachment of the administrative object.
[11] The administrative data can be associated with corresponding administrative data; An administrative management system described in any of [1] to
[10] , wherein the administrative data from previous years referenced when registering new administrative data includes identification information for the new administrative data.
[0008] The invention of [1] makes it possible to manage workflows based on issues linked to administrative objects, thereby enabling administrative activities to be promoted efficiently.
[0009] The invention according to [2] makes it possible to manage the workflow for multiple administrative objects, thereby enabling administrative activities to be promoted efficiently.
[0010] The invention of [3] makes it possible to manage workflows based on issues linked to administrative objects, thereby enabling administrative activities to be promoted efficiently.
[0011] The invention of [4] makes it possible to efficiently promote administrative activities while flexibly adjusting the scope of disclosure, for example, by disclosing issues to decision makers while keeping documents under adjustment confidential.
[0012] The invention of [5] makes it possible to efficiently promote administrative activities, for example, when an issue assigned to the head of the original department is handled by the person in charge of the original department.
[0013] The invention of [6] makes it possible to efficiently promote administrative activities while flexibly adjusting the scope of disclosure.
[0014] The invention in [7] enables efficient administrative activities using issues.
[0015] The invention of [8] makes it possible to efficiently promote administrative activities, including users outside the workflow.
[0016] The invention of [9] makes it possible to determine the progress of a workflow based on communication within an issue.
[0017] The invention of
[10] enables efficient administrative activities using issues.
[0018] The invention of
[11] makes it possible to efficiently promote administrative activities while maintaining relationships with administrative data from previous years, such as continuing or merged administrative projects, and administrative projects that have been commercialized as administrative issues. [Effects of the Invention]
[0019] According to the present invention, it is possible to provide a technique for efficiently promoting administrative activities in an administrative organization. [Brief explanation of the drawings]
[0020] [Figure 1] FIG. 1 is a system configuration diagram of the present embodiment. [Figure 2] FIG. 2 is a diagram illustrating a hardware configuration of the present embodiment. [Figure 3] 3 shows an example of a data configuration according to the present embodiment. [Figure 4] 10 is a screen display example of an administrative business group registration screen according to the present embodiment. [Figure 5] 3 is a flowchart showing a workflow process according to the present embodiment. [Figure 6] 10 shows an example of a workflow start screen display according to the present embodiment. [Figure 7] 10 shows an example of the progress of a workflow according to this embodiment. DETAILED DESCRIPTION OF THE INVENTION
[0021] The administrative management system, administrative management method, and administrative management program of the present invention will be described below with reference to the accompanying drawings. Note that the following embodiment is an example of the present invention, and the present invention is not limited to the following embodiment, and various configurations can be adopted.
[0022] In this embodiment, the configuration, operation, etc. of an administrative management system will be described, but similarly configured methods, devices, computer programs, and program recording media storing such programs can also achieve similar effects. The series of processes according to this embodiment described below is provided as a computer-executable program, and can be provided via a non-transitory computer-readable recording medium such as a CD-ROM or flexible disk, or even via a communication line.
[0023] <1.1. Definitions of terms, etc. 1> The definitions of terms and phrases used in this specification are as follows: An administrative organization is an organization that manages administration, including government agencies, ministries, public organizations, etc., such as national and local governments, and in this embodiment, a local government is used as an example. The administrative management system according to the present invention is used in administrative organizations to operate and manage administrative activities. The policy system is a system of issues divided into three layers: policy, measures, and business operations. In this embodiment, an example is given of a case where business operations are managed using this policy system, but business operations may be managed by dividing into four or more layers, for example, by providing a layer of sub-measures between measures and business operations. A policy is a large set of administrative activities aimed at realizing basic guidelines for addressing specific administrative issues, and indicates the direction and objectives of urban development in the established administrative division (city, ward, town, village, etc.). A policy is a set of administrative activities based on the basic principles of a policy and aimed at realizing a specific policy, and indicates the measures and countermeasures for realizing the policy. Tasks and projects are administrative procedures and projects that are carried out as individual administrative means to materialize specific policies in policies. Tasks and projects are implemented by each bureau within an administrative division based on its budget.
[0024] An administrative object refers to an object handled in administrative activities. In this embodiment, the administrative object is assumed to manage individual administrative tasks, projects, answers, and issues. Answers refer to plenary session answers and committee answers prepared by executive bodies such as administrative agencies in response to questions from members of parliament. Issues are issues collected during the planning, execution and evaluation stages of administrative projects, as well as by parliaments and committees, and serve as the basis for formulating administrative issues for the next term and beyond. In addition, for example, policies and the like may also be managed as administrative objects.
[0025] <1.2. Overview of administrative activities> An example of the flow of administrative activities will be explained. Administrative operations: First, in the planning stage, plans for administrative operations to be implemented in the next planned execution fiscal year (for example, the following fiscal year) are prepared. Next, in the budget compilation stage, budget requests for administrative operations to be implemented in the next planned execution fiscal year are prepared, the budget requests are assessed, a budget proposal is prepared, and it is submitted to the assembly. Then, in the execution fiscal year, in the execution stage, the budget is executed for administrative operations approved by the assembly. In the evaluation stage, administrative evaluation reports are prepared for the executed administrative operations. Answers: Record the notified content of questions and general questions at plenary sessions and committees as needed, and input and manage the content of answers regarding the notified content, and prepare answers to plenary sessions and committee responses, etc. Issues: Issues collected during the planning, execution, and evaluation stages of administrative projects, as well as by the assembly and committees, will be evaluated from time to time, and new administrative projects that address the issues will be registered at the planning stage for the next planned execution year and beyond, or perspectives related to the issues will be incorporated into existing administrative projects.
[0026] <1.3. Definitions of terms etc.2> A topic refers to a gradual division of administrative activities carried out with an administrative object as the objective. One or more topics can be defined for each type of administrative object. In this embodiment, for example, when the objective is an administrative project, topics are defined as multiple divisions arranged chronologically, such as "Plan," "Budget Preparation > Request," "Budget Preparation > Assessment," "Budget Preparation > Preliminary Notice," "Budget Preparation > Resolution," "Budget Execution," "Settlement," and "Administrative Evaluation." Furthermore, when the objective is a response, topics such as "Response Management" for creating responses to questions are defined. When the objective is an issue, topics such as "Issue Management" for accumulating and managing collected issues and elevating them to projects are defined. The above is just an example; different divisions, abstract divisions, detailed divisions, etc. may also be defined. Furthermore, topic subdivision may be achieved by hierarchizing topics into multiple layers. For example, instead of the topic "Budget Preparation > XX," categories such as "Initial Budget Preparation (hereinafter referred to as "Initial") > XX" and "Supplementary Budget Preparation (hereinafter referred to as "Supplementary") > XX" may be defined, or subtopics of "Initial Budget > XX" and "Supplementary Budget > XX" may be defined in layers under "Budget Preparation." Furthermore, multiple categories arranged chronologically may also be defined as topics in lower layers. For example, categories such as "Request," "Assessment," "Unofficial Notice," and "Resolution" may be defined in layers under "Budget Preparation."
[0027] An issue refers to a topic in carrying out administrative activities that occur for each administrative object. An issue is associated with an individual or a group of administrative objects and assigned to a specific person in charge. In this embodiment, an issue is raised for an administrative object of a specific topic or a group of administrative objects that belong to a specific topic.
[0028] A workflow is a repeatable, defined flow of administrative activities. In this embodiment, the workflow includes multiple stages (WS) that are executed to achieve a certain goal, and progresses by completing issues assigned to individuals in each stage (WSn).
[0029] Workflows support the progress of administrative activities for administrative objects, but may also have the purpose of transitioning administrative objects to the next topic or making them ready to transition. For example, a workflow for the "Planning" topic is the former, and completing it allows the object to transition to the next "Budget Preparation" topic. For example, a workflow for the "Budget Preparation > Resolution" topic is the latter, and once the workflow is complete, the task can transition to the "Execution" topic when the scheduled execution year arrives. Alternatively, a workflow may be intended for administrative activities that are carried out repeatedly in a specific topic. For example, a workflow for the "Execution" topic includes stages such as application to approval, and can be executed one or more times for each task during the budget execution period.
[0030] 2.1. System Configuration Fig. 1 shows a system configuration diagram of an administrative management system 1. As shown in Fig. 1, the administrative management system 1 comprises an administrative management device 2, a user terminal 3, and a database DB, and each component is connected to a communication network NW. For example, the communication network NW includes a comprehensive administrative network (LGWAN: Local Government Wide Area Network), and the administrative management device 2 and the database DB, and the administrative management device 2 and the user terminal 3 are connected via the comprehensive administrative network.
[0031] The administrative management system 1 (administrative management device 2) provides a platform for operating and managing administrative activities related to administrative objects such as administrative projects, etc. The administrative management device 2 comprises, as functional components, an administrative object management unit 21, an administrative object group management unit 22, an issue management unit 23, an issue group management unit 24, and a workflow management unit 25.
[0032] The user terminal 3 is a terminal device used by a user belonging to an administrative organization, etc. A plurality of user terminals 3 are installed at least within the administrative organization.
[0033] In this embodiment, users include special officials (such as mayors) within administrative organizations, users of the Finance Division and other secretariat departments, section chiefs, department heads, civil engineering departments (bureaus and sections), agriculture, forestry, and fisheries departments (bureaus and sections), and users and supervisors of original bureaus and original sections (section chiefs, department heads, etc.). For example, original section users perform tasks such as creating project documents such as business plans, creating budget requests, executing budgets, and creating administrative evaluation reports. Secretariat users perform tasks such as requesting original section users to create budget requests and evaluating budget requests. Section chiefs, department heads, and special officials perform tasks such as reviewing user deliverables, selecting and prioritizing priority projects based on plans, and assessing budget requests approved by finance division users. The administrative management system 1 assigns predetermined operational authority to each user and controls the permission and restriction of predetermined functions according to the operational authority. In particular, users who perform processing at a certain stage of a workflow are referred to as "persons in charge."
[0034] 2.2. Hardware Configuration FIG. 2(a) shows a hardware configuration diagram of the administrative management device 2. The administrative management device 2 includes, as its hardware configuration, a control unit 201, a storage unit 202, and a communication unit 203. In this embodiment, the administrative management device 2 can be a computer device such as a server or a personal computer. Note that the administrative management device 2 may be configured with multiple computer devices, and is not limited to the configuration shown in FIG. 2(a) as long as the above-described functional components (21-25) can be realized as a whole.
[0035] The control unit 201 is configured with one or more processors such as a CPU, and controls the overall processing of the administrative management device 2 by executing an administrative management program, an OS (Operating System), and other applications. The storage unit 202 is configured with one or more memories such as an HDD (Hard Disk Drive), SSD (Solid State Drive), flash memory, RAM (Random Access Memory), etc., and stores the administrative management program and various data. The communication unit 203 controls communication with the communication network NW, and realizes data communication with the user terminal 3 and the database DB. By executing the administrative management program, the control unit 201 causes the computer to function as the administrative management device 2 and execute the administrative management method.
[0036] In the illustrated example, the database DB is a database server accessible via a communication network NW including LGWAN, etc., but it may also be realized using, for example, the control unit 201 and memory unit 202 that constitute the administrative management device 2, or it may be connected to the administrative management device 2 via a LAN, etc.
[0037] 2(b) shows a hardware configuration diagram of a terminal device 9 such as the user terminal 3. The terminal device 9 includes, as its hardware configuration, a control unit 901, a storage unit 902, a communication unit 903, an input unit 904, and a display unit 905. In this embodiment, the terminal device 9 may be a smartphone, a personal computer, a tablet terminal, or the like.
[0038] The control unit 901 is composed of one or more processors such as a CPU, and controls the overall processing of the terminal device 9 by executing an OS and other applications. The storage unit 902 is an HDD, SSD, flash memory, RAM, etc., and stores a browser application and various data. The communication unit 903 controls communication with the communication network NW and realizes data communication with the administrative management device 2. The input unit 904 is an input interface that accepts operation requests from an operator, and is composed of a touch panel, mouse, keyboard, etc. The display unit 905 is composed of a display that displays the processing results of the control unit 901, etc.
[0039] <2.3.Database> The database DB will store user master data in advance, as well as previous years' administrative and business information (administrative data), business group information, issue information, issue group information, workflow information, and response information (administrative data) and issue information (administrative data).
[0040] The user master stores user information within an administrative organization. The user information includes the user's identification information (user ID), name, department (division, section, etc.), etc. It may also be possible to define a user group, which is a collection of one or more users. The user group information may be predefined, for example, by the user group's identification information (user group ID) and the identification information of the users belonging to the user group, or users with a common attribute (department) may be treated as a user group. Users to be included in a predefined user group may be arbitrarily selected, or may be selectable from user groups with a common attribute. A user group is specified by an arbitrarily set group name or an attribute name that represents the characteristics of the group.
[0041] The business and project information is administrative data related to each business and project, and is registered for each planned execution year. In this embodiment, the business and project information includes basic information related to the business and project (basic business information), administrative goal information, budget information, and execution information related to the business and project. Basic information on administrative projects (basic information on administrative projects) is information on the content of administrative projects, and includes the identification information (administrative project ID) of the basic information (i.e., administrative project information), the planned execution year, the identification information (administrative project ID) of the related administrative data described below, the status, and multiple data items related to the project's business forms. Data items in the basic information (basic information on administrative projects) include, for example, the project number, project name, responsible department (division, section, office, etc.), project start year, project (planned) end year, accounting classification, underlying laws and regulations, the main policies and measures to which the administrative project belongs, the project purpose, project overview, implementation method, and other various information related to the project.
[0042] The status of basic information (basic administrative project information) indicates the stage of the project in administrative activities and includes at least one status corresponding to the topic. For example, statuses such as "Plan," "Budget Preparation > Request," "Budget Preparation > Assessment," "Budget Preparation > Preliminary Notice," "Budget Preparation > Resolution," "Execution," and "Administrative Evaluation" are assigned. Here, projects that receive a zero rating (not budgeted) at the "Budget Preparation > Preliminary Notice" stage retain the status "Budget Preparation > Preliminary Notice." "Budget Preparation > Assessment" includes projects before and during assessment, as well as projects that have been put on hold as a result of assessment. "Budget Preparation > Request" includes projects at the budget request stage and projects that have been put on hold but for which a request for revival has been made. These statuses are merely examples; the stages of each status can be arbitrarily divided, and the number of stages is not limited to these. In addition to, or instead of, the staged status corresponding to the topic, statuses related to the assessment results (such as budgeted or not budgeted), or the evaluation results of the administrative project (such as continued or canceled), may also be assigned.
[0043] Administrative goal information defines the KPIs for achieving each task, i.e., the tasks that must be achieved during the execution period of the task. Administrative goal information may be set in multiple stages for each task. Administrative goal information includes identification information for the administrative goal (administrative goal ID), as well as data items such as the content of the administrative goal and the deadline for achieving the administrative goal. In addition to the deadline, it may also include a reminder timing.
[0044] The budget information includes initial budget information indicating the initial budget for a certain business project, and supplementary budget information indicating the supplementary budget. The initial budget information includes identification information for the initial budget (initial budget ID), identification information for related administrative data (business ID), and multiple data items related to the initial budget. The data items of the initial budget information include, for example, an outline of the initial budget, items such as sub-items related to the budget, and the requested budget amount. The supplementary budget information includes identification information for the supplementary budget (supplementary budget ID), monthly data, identification information for related administrative data (initial budget ID), and multiple data items related to the supplementary budget. The data items of the supplementary budget information include, for example, an outline of the supplementary budget (purpose, reason, etc.), items such as sub-items related to the budget, and the requested budget amount. Note that the items related to the initial budget and supplementary budget are just examples, and items of any granularity such as sections and subsections may be included. For example, these items may be stored in an item master, and in the business information, they may be referenced by identification information (item ID) in the item master.
[0045] Execution information is information that is registered as needed for budget execution during the execution period. Execution information includes execution identification information (Execution ID), identification information for the task or project for which the budget is executed (Project ID), and data items such as execution date, item, and amount of execution. Sections and subsections may be added to the item when registering the execution information.
[0046] The assignment information is administrative data relating to individual assignments. In this embodiment, the assignment information includes assignment identification information (assignment ID), identification information for related administrative data (business ID), and multiple data items relating to the assignment. Data items of the assignment information include, for example, the assignment name, assignment content, relevant policies, measures, administrative projects, supervising organization, and assignment creator (user ID).
[0047] The reply information is administrative data relating to each reply. In this embodiment, the reply information includes reply identification information (reply ID), related administrative data identification information (issue ID), and multiple data items relating to the reply. Data items for reply information related to the plenary session include, for example, the name of the assembly, the date of the plenary session, the name of the member who asked the question, the party that asked the question, the type of question (general question / urgent question), the content of the question, the classification of the person replying (head of the local government, department head, section head, etc.), the department responsible for preparing the reply (department, section office, etc. (consultation point)), the content of the reply, and the person who prepared the reply (user ID).
[0048] <2.4. Example of data structure based on related administrative data> FIG. 3 is a diagram illustrating an example of related administrative data. Related administrative data is administrative data related to a certain administrative data, and one or more pieces of related administrative data may be set. Examples of related administrative data include information on previous years' administrative projects when a task or project is continued, information on other tasks and projects when a task or project is integrated, information on the issues that led to the task or project, and information on responses that led to the administrative issues. In this embodiment, each piece of administrative data is associated using a reference structure such as that shown in FIG. 3. When a task or project is continued or integrated, the newly registered task or project information is associated with the corresponding task or project information using related administrative data. The identification information for the related administrative data of the basic task and project information (execution year: 2022) is blank when it is registered. When new task and project information is registered as a continuation of the task or project, the identification information (task and project ID) for the new task and project information is entered. In the illustrated example, the basic task and project information (execution year: 2023) (task and project ID: 2222) is assigned as the related administrative data for the basic task and project information (execution year: 2022). In addition, if multiple projects from previous years are integrated, the same identification information for the new project information (project ID) will be entered into multiple pieces of project information from previous years. When integrating projects, the project information for the current year associated with the project information for the previous year for the main project and the project to be integrated can be registered, and then the project information for the integrated project can be associated as related administrative data for the project information for the main project for that year. When an administrative issue is turned into a business, the newly registered business information is associated with the issue information accumulated in the immediately preceding period, etc., through related administrative data. In the illustrated example, the related administrative data in the issue information (implementation year: 2021) is the business that corresponds to the issue or that has evolved from the issue (business ID: 1111). When accumulating administrative issues from the content of responses, the newly registered issue information and the accumulated response information are associated with related administrative data. In the illustrated example, the related administrative data for the response information (execution year: 2021) is the issue (issue ID: 9999) that was elevated from the response. The related administrative data for the initial budget information (implementation year: 2023) is the basic information on administrative operations related to the budget (implementation year: 2023) (administrative operations ID: 2222). The related administrative data in the supplementary budget information is, for example, the initial budget information (initial budget ID: 3333) relating to the supplementary budget. The related administrative data in the supplementary budget information may be, for example, the immediately preceding supplementary budget. In the illustrated example, when new administrative data is registered, the correspondence is achieved by assigning the identification information of the new administrative data to the previously registered administrative data, but the correspondence can also be achieved by assigning the identification information of the previously registered administrative data to the newly registered administrative data.
[0049] <3.1.Registration of administrative object groups> <3.1.1. Registration of administrative objects (administrative data)> The registration of administrative object groups will be explained with reference to FIG. The administrative object management unit 21 registers administrative data related to administrative objects. For example, the administrative object management unit 21 stores various administrative data in the database DB based on a request to register new administrative data such as administrative business information, issue information, and response information, and edits existing administrative data. In addition, the administrative object management unit 21 uses data items included in the issue information stored in the database DB to register administrative business information with corresponding data items input (preset), and uses data items included in the response information stored in the database DB to register issue information with corresponding data items input (preset).
[0050] 3.1.2.Status of administrative objects The administrative object management unit 21 sets the status of administrative objects. In the above example, a status is assigned to administrative business information, but a status may also be assigned to answer information or issue information depending on the stage or state of the topic (before approval, under approval, etc.). The administrative object management unit 21 changes the status of an administrative object, for example, when the workflow of a certain topic is completed. Instead of or in addition to the completion of the workflow, the status may be changed depending on the planned execution year and actual date and time of the administrative object.
[0051] <3.1.3. Authority of administrative objects> The administrative object management unit 21 also manages the authority for administrative objects. The authority may be, for example, the authority to view administrative data or the authority to edit and view administrative data. The authority may be for at least some of the data items of the administrative data, or may be for all of the data items. The authority is set for a user group or an individual user. The authority for administrative objects may be granted to a user other than the user designated as the person in charge of the workflow. In this embodiment, the authority to view administrative objects and the authority to edit and view administrative objects are set according to the department to which the user belongs.
[0052] Note that viewing and / or editing permissions may be changed depending on one or more of the topics to which administrative objects belong and the workflow stages. For example, in the "Budget Preparation > Request" topic, users from the original department can enter data items for the task, but when they submit it to their superior and the workflow stage advances, or for the task that has advanced to the "Budget Preparation > Assessment" topic, editing permissions are revoked. Such changes in permissions may differ depending on the department or position. For example, even in the "Budget Preparation > Assessment" topic, users from the Secretariat department may be able to edit the task.
[0053] <3.1.4. Administrative Object Version> When administrative data is updated, the administrative object management unit 21 records the history and manages versions of the administrative data. In this embodiment, the person in charge at each stage in the workflow registers a version for the administrative data. When registering a version of administrative data, user groups and users with viewing permissions for the original version of the administrative data are preset, and any user groups or individual users can be added or deleted as needed. The administrative object management unit 21 may automatically register versions as the workflow progresses. Note that versions may be registered even when they do not necessarily involve edits to the administrative data. Furthermore, instead of or in addition to registering versions according to the workflow stage, the administrative object management unit 21 may register versions when edits are made to the administrative data and / or when the topic of the administrative data is changed. For example, when the workflow for updating and approving administrative data is completed, the administrative object management unit 21 stores a new version of the administrative data. For example, the administrative object management unit 21 for a certain topic may manage permissions for each version of the administrative object.
[0054] <3.1.5. Administrative Object Group> The administrative object group management unit 22 registers administrative object groups, which are collections of multiple administrative objects. The administrative object group management unit 22 is used when multiple administrative objects are grouped together and placed on a workflow. The administrative object group management unit 22 can group administrative objects if they have at least one or more of the following items in common: (1) Planned execution year (2) Type of administrative object (business, response, issue, etc.) (3) Budget type (initial budget, supplementary budget) (4) Topic to which the administrative object belongs (status in business information) In this embodiment, the administrative object group management unit 22 groups all or selected administrative objects among the administrative objects that have all of (1) to (4) in common into one administrative object group, and stores the administrative object group information in the database DB. The selected administrative object may be an administrative object arbitrarily selected by the user, or may be an administrative object identified by a specific data item arbitrarily designated by the user (for example, a policy or a responsible department).
[0055] The administrative object group information includes identification information of the administrative object group (administrative object group ID), the group name, the planned execution year, the topic, and identification information of multiple administrative objects belonging to the group.
[0056] <3.1.6.Administrative Object Group Registration Screen> 4 shows an example of the screen display of the administrative object group registration screen W4 displayed on the display unit 905 of the user terminal 3. The administrative object group registration screen W4 has an input field W41, an administrative object display field W42 within the group, a search field W43, a search result list W44, and a save button W45. A user of an original bureau or original department, for example, enters the name of a group of administrative objects (in the illustrated example, the name of a business or administrative project group) in the input field W41 via the input unit 904 of the user terminal 3, and also specifies the topic of the administrative objects to be included in the group. In addition, various data items related to business or administrative projects are entered as search criteria in the search field W43 to search for business or administrative projects to be included in the group.
[0057] The search field W43 allows users to enter keywords for searching for the planned execution year of an administrative object or topic (status) data items (e.g., accounting classification, policies, measures, budget information, and execution information subjects for administrative projects). These keywords can then be used to search for administrative objects. The topics that can be specified in the search field W43 are subordinate topics corresponding to the topic specified in the input field W41. The searched administrative objects are displayed in the search result list W44, and can be added to a group by pressing the corresponding Add button. Furthermore, by pressing the Details button, information (e.g., project forms related to administrative projects) can be displayed on the display unit 905 of the user terminal 3 based on the administrative data. When the Save button W45 is pressed, the administrative object group management unit 22 stores the administrative project group information, including the group name, topic, and added administrative project entered in the input field W41, in the database DB, and registers the administrative project group. In this embodiment, a topic is set for each administrative object group. However, for example, a topic may be specified when selecting an administrative object group and starting a workflow. In this embodiment, we have explained the registration of administrative business groups, which are groups of administrative businesses, but administrative objects such as issues and replies can also be organized into groups on the same screen by narrowing down the search by fiscal year or other data items.
[0058] <3.2. Registering an Issue Group> <3.2.1. Registering an Issue> The issue management unit 23 registers issues associated with administrative objects. In this embodiment, the issue management unit 23 registers issues by storing issue information in a database DB. When an issue is registered, the person in charge is notified that the issue has been registered, and the person in charge checks the content of the issue and performs administrative activities. The issue management unit 23 registers issues based on a request from a user to create an issue or a request to start a workflow. Note that a user may be able to register an issue with himself or herself as the person in charge.
[0059] Issue information includes the identification information of the issue (issue ID), and as data items of the issue, the identification information of the corresponding administrative object (business ID, response ID, task ID), the title and content of the issue, one or more responsible persons, the creator of the issue, the issue status, the deadline, attachments, work items, the type of issue, and the identification information of the issue group (issue group ID) described below.
[0060] The issue management unit 23 sets the person in charge of an issue in at least one of the following ways. (11) A user or user group selected by the user who creates an issue or initiates a workflow (12) Users and departments set in the administrative data linked to the issue (13) Users (user groups) selected according to the attributes (affiliation, position, etc.) selected by the user who creates an issue or starts a workflow When a user group is designated as the person in charge, the issue management unit 23 may assign the leader of the group to the issue, or may assign multiple users belonging to the group to the issue. Alternatively, each administrative object may be linked to an individual user, and a user in the user group designated as the person in charge of the issue, or a user under an individual user (e.g., a supervisor) designated as the person in charge, may be assigned as the person in charge of the issue according to the user linked to the administrative object. Furthermore, the person in charge of an issue and the user who actually performs the work may be different. For example, an individual user (e.g., a supervisor) may be assigned to the issue as the person in charge, and the work (e.g., inputting data items) may be performed by another user (e.g., a user under the supervisor) in response to a request in real life or a request (mention) via a thread, which will be described later. Issue types include a type with an input form linked to an input form for inputting one or more specific data items, and a type without an input form. When an input form is included, input fields for any one or more data items are placed on the issue display screen or on an input screen that can be moved from the issue display screen, and the user can input data values for the data items through these input fields.
[0061] <3.2.2. Issue Status> The issue management unit 23 sets the person in charge of an issue and the issue status. The issue status may be, for example, "Work Required," "Returned," or "Completed." The issue management unit 23 may change the issue status in response to a completion operation from the issue creator, or may change the issue status when the workflow ends.
[0062] <3.2.3. Issue Authority> The issue management unit 23 also manages authority for issues. The authority includes, for example, issue viewing authority and responsible person authority. The viewing authority may be for at least some of the data items of an issue, or may be for all of the data items. The responsible person authority relates to changes in the issue status and workflow progress, such as submission, approval of submitted content, and return. A user who is assigned an issue and has the responsible person authority enabled performs tasks requested by the issue title, content, topic of the corresponding administrative object, etc. The tasks include, for example, entering data items, registering created attachments to the issue, editing (and reattaching) attachments to the issue, and entering data items from a linked input form.
[0063] Permissions are set for user groups or individual users. Viewing permissions for issues may be granted not only to the person in charge of the current workflow stage WS, but also to people in charge of other stages and users other than the person in charge. In this embodiment, viewing permissions for issues are set according to the user's department (user group), and the person in charge of an issue is transferred between people in charge of the issue according to the workflow stage WS. For example, a first person assigned to an issue is granted person in charge permissions. When the first person completes the issue (e.g., submits), the first person's person in charge permissions are revoked, and person in charge permissions (e.g., approve / reject) are transferred to the person in charge of the next stage WS (the second person in charge). The viewing permissions for administrative objects and issues may be linked, or different scopes may be set for each. In this embodiment, the viewing permissions for administrative objects and issues each target different scopes.
[0064] <3.2.4.Thread> An independent thread (message thread) can be created on an issue, at least for each issue. In this embodiment, users (including responsible parties) can communicate with other users via messages on a thread regarding administrative activities for a certain administrative object. Messages exchanged on a thread include at least text, and messages and / or threads are set with at least one of mention, posting purpose, subject of criticism, usage permissions, and status. Mention indicates any user or user group to be notified of the creation of a thread and / or the posting of a message, and one or more of these can be specified. The posting purpose indicates the purpose of creating a thread or posting a message, and one or more can be set. Some or all of the posting purpose may be predefined (e.g., "point out" or "return"), or it may be written using free text. The point out target specifies the data item or attachment of the administrative object that the thread or message targets. Usage permissions include the permission to view the thread, the permission to view individual messages, and the permission to post messages. The status indicates the state of communication in the thread (e.g., "in progress", "completed", etc.). In addition, the message may include a reference (reply) to any message.
[0065] In this embodiment, the issue management unit 23 creates a thread associated with an issue based on a request from a user. When creating a thread, it accepts settings for the posting purpose for the thread, the setting of the target of the criticism, the setting of permissions, and the setting of mentions for any user. Posting purposes include those that are predefined and those written as text, and one or more posting purposes set for the thread are added as tags. In addition, the issue management unit 23 changes the status of the thread from in progress to completed when the thread creator completes the thread, controls user access based on the permission settings, and accepts the posting of a text message for the thread and any reply settings. When the administrative object management unit 21 manages the version of an administrative object, the issue management unit 23 may further accept settings for the version of the administrative data targeted by the thread or a message on the thread, and indicate the version of the administrative object targeted by the message in the thread along with the posting purpose of the thread, etc.
[0066] <3.2.5. Thread and Message Permissions> A thread for which no usage permissions have been set is called an open thread, and a thread that can only be used by users with usage permissions is called a private thread. Open threads can be used by users who have permission to view the corresponding issue. For example, when advancing a workflow step, a message can be written along with the completion operation of the issue, and messages such as matters to be passed on when the completion operation is performed are posted to the open thread. Private threads can only be used by users who have permission to view the issue and who also have permission to use the thread. Permission to use a private thread is set by the user who created the thread. When the administrative object management unit 21 manages permissions for each version of an administrative object, the issue management unit 23 may further accept the setting of the version of administrative data targeted by the private thread or the message on the private thread, and grant usage permissions for the private thread or the message on the private thread to some or all users who have viewing permissions for the corresponding version of the administrative object and the issue. When registering a private thread or a message on the private thread linked to a version of administrative data, the user groups and users who have permissions for the issue and the administrative data of that version are preset, and any user group or individual user can be deleted as needed. The issue management unit 23 may automatically register usage permissions for the private thread or the message on the private thread according to the permissions for the issue and the administrative data of that version, and at this time, usage permissions may be granted based on an AND condition with other conditions of the private thread.
[0067] <3.2.6. Generation of issue information according to workflow> In this embodiment, the person in charge of an issue is updated for each workflow stage WS and moves between different people in a manner similar to a Kanban system. This allows information (such as comments) associated with issues in previous stages WS to be retained for reference. On the other hand, new issue information associated with the same administrative object may be generated for each workflow stage WS (each person in charge). In this case, for example, by including the identification information or serial number of the immediately preceding and / or succeeding issue in the successive issue information in the workflow or in the workflow information, the chronological order and order of the corresponding issues, as well as information associated with each issue (such as comments), can be retained for reference.
[0068] <3.2.7. Issue Group> The issue group management unit 24 registers an issue group. In this embodiment, the issue group management unit 24 registers an issue corresponding to each of all administrative objects included in a specified administrative object group in the issue management unit 23, and stores issue group information related to an issue group consisting of these issues in the database DB, thereby registering the issue group. The issue group information includes identification information of the issue group (issue group ID), the group name, and identification information of the corresponding administrative object group (administrative object group ID).
[0069] <3.3. Registering workflow information> The workflow management unit 25 registers workflow information and manages the processing status of the workflow using the processing status of the issues listed in the workflow. The person in charge of processing in the first stage of the workflow follows the method for determining the person in charge of the issue. The workflow management unit 25 sets the person in charge of the second and subsequent stages of the workflow using at least one of the following methods. (21) A user who starts a workflow, or a user or user group selected by a person in charge of a certain stage WS (22) Users and departments set in administrative data (23) A user or user group selected according to attributes (affiliation, position, etc.) defined for each stage WS of the workflow When multiple people are designated, the order in which they are assigned, i.e., the order of the workflow stages WS, is also specified. One person in charge may be assigned to each stage of the workflow (serial), or multiple people may be assigned to some stages in the workflow (parallel). In this case, the stage may advance only when some of the people in charge have given their approval, or when all of the people in charge have given their approval.
[0070] The workflow management unit 25 inserts a stage based on a request from a person in charge. It is preferable that a person with authorized person authority can insert a stage. For example, a person in charge of a certain stage WSn can designate a person in charge of WSn1 and insert a stage WSn', requesting work or confirmation (approval) from the person in charge of stage WSn'. The person in charge of the inserted stage WS may also be able to insert another stage WS. A person in charge of a certain stage WS may designate multiple people and request work from multiple people (in parallel) in stage WSn'. When a completion operation (submission or approval) is performed in stage WSn' of an inserted workflow, the issue is handed over to the person in charge of the next stage WSn+1. The issue may then be returned to the person in charge of the immediately preceding stage WSn, who may then perform a completion operation on the issue, allowing the workflow to proceed to the next stage WSn+1. When multiple people are working in parallel, multiple people may be assigned to each issue. Furthermore, if the immediately preceding person has multiple issues, some or all of them may be distributed and assigned.
[0071] A user who starts a workflow starts it by specifying at least the first person in charge. Workflows include workflows defined for each topic and workflows that can be executed at any time. In a workflow defined for each topic, at least two people participate: the person in charge of tasks such as entering and checking data items (or supervising the entry and work), and the final approver. There may be one or more intermediate approvers before the final approver, and when the person in charge completes the issue, the issue is assigned to the next intermediate approver. If there are two or more intermediate approvers, the issue is assigned to the next intermediate approver when the previous intermediate approver completes the issue. If there is only one intermediate approver, or when the last intermediate approver completes the issue, the issue is assigned to the final approver. When the final approver completes the issue, the workflow creator is notified and the issue is assigned.
[0072] At each stage WS of the workflow, processing is performed such as creating a specified administrative object, inputting data items, and confirming (approving) the input data items. The workflow management unit 25 may define the processing that is possible at each stage of the workflow in at least one of the following ways: (31) The process selected by the user who starts the workflow or the person in charge of a certain stage WS (32) Processing selected from the user or user attributes set in administrative data (for example, the person in charge of the original department inputs data items, and the section chief or department manager approves the data, etc.) (33) Processing defined for the workflow stage WS (for example, input at stage WS1 or stage WS1' inserted at stage WS1, confirmation at stage WS2 and after) The issue status corresponds to this process, and may be set to, for example, "inputting," "before intermediate approval," "intermediate approval completed," "before final approval," "final approval completed," or the like.
[0073] Workflows that can be executed at any time are executed by a minimum of two people for questions, consultations, etc. For example, an issue containing the sender's question or consultation is assigned to the sender and destination users, and the destination user's person in charge authority is enabled. When the destination user (person in charge) completes the issue by writing a response comment, etc., the sender user's person in charge authority for the issue is enabled. If the sender user has resolved the question or consultation, the workflow ends by completing the issue. If the issue is not resolved, the issue progresses to the next stage, and the destination user's person in charge authority is re-enabled.
[0074] The topic, administrative object, responsible person, and timing may be defined in advance to schedule the start of the workflow. For example, the start date of the workflow may be registered, and when the start date arrives, an issue may be registered in the issue management unit 23 to start the workflow. Also, for example, based on the reminder timing included in the administrative goal information, the issue of administrative goal information registration may be assigned to the responsible person associated with the administrative goal information, and the workflow for administrative goal information registration may be started.
[0075] The workflow management unit 25 determines the processing status of the workflow based on the processing status of the issues listed in the workflow. The processing status of an issue includes the issue status of the issue, the person in charge of the issue (workflow stage), etc. The processing status of the administrative object group (workflow) can also be determined from the processing status of the issue group. The processing status of the issue group includes the aggregated results of the issue status of the issues in the issue group, the aggregated results of the workflow stages, the aggregated results of the posting intent attached to the topic or message, etc.
[0076] <4.1. Workflow processing flow> Next, we will explain the case where an issue group is placed in a workflow linked to a topic using Figure 5. First, a user who wants to start a workflow registers the administrative object group that will be the target (see S501 in Figure 5). Then, via a workflow registration screen such as that shown in Figure 6, the user specifies the administrative object group and starts the workflow (see S502 in Figure 5).
[0077] FIG. 6(a) shows an example of a workflow start screen W6a displayed on the display unit 905 of the user terminal 3. The workflow start screen W6a includes a workflow information input field 6a1 and a start button W6a2. The user inputs, into the workflow information input field 6a1, the workflow name, the administrative object group that will be the target of the workflow (in the illustrated example, the administrative business group), the person in charge of processing each stage of the workflow, a progress schedule indicating the start date and end date of the workflow, and a message regarding instructions for the person in charge, an explanation of the workflow content, etc., and then presses the start button W6a1 to start the workflow. In this embodiment, the start date and end date of the workflow are set as the deadline for the issue, and the workflow content is set as the content of the issue in the issue information.
[0078] In this embodiment, the user who registered the workflow will designate in advance the person in charge at each stage of the workflow. In the example of Fig. 6, when the workflow is started, issues are assigned to the persons in charge "AAA", "BBB", and "CCC", and the person in charge authority of the person in charge "AAA" is first validated. Then, when the person in charge "AAA" completes the issue, the person in charge authority of the next person in charge "BBB" is validated. Then, when the person in charge "BBB" completes the issue, the person in charge authority of the last person in charge "CCC" is validated. Furthermore, it may be possible to assign the issue to another person in charge (inserting a stage) before proceeding to the next stage WS. For example, before person in charge "AAA" completes the issue, another person in charge "DDD" can be designated and assigned the issue. In this case, when person in charge "DDD" inserted in the progress of the workflow completes the issue, the person in charge authority of person in charge "BBB" after person in charge "AAA" may be validated, or the person in charge authority of the original person in charge "AAA" may be re-enabled. In this case, the handover of work between person in charge "AAA" and "DDD" may be registered as separate workflow information.
[0079] The workflow information includes the workflow identification information (workflow ID), the workflow name, the identification information (administrative object group ID) of the administrative object group (in the illustrated example, the administrative business group) that is the target of the workflow, the person in charge, the progress schedule, and a message.
[0080] When a workflow is started, the issue management unit 23 registers an issue for each individual administrative object belonging to the administrative object group associated with the workflow, and the issue group management unit 24 registers an issue group consisting of these issues (see S503 in FIG. 5), and the issue management unit 23 assigns the registered issues to persons in charge 1 to N (see S504 in FIG. 5). Persons in charge can display a list of the issues assigned to them, and can also display issue information that allows them to refer to data items related to the associated administrative objects. Note that users can view issues that are not assigned to them and post messages, etc., depending on their issue authority settings.
[0081] The workflow includes multiple stages WSn. First, stage WS1 is started (see S505 and S506 in FIG. 5), and the issue management unit 23 grants responsible person authority to person in charge 1. Person in charge 1 performs the work and performs a completion operation on the issue (S507 in FIG. 5). The issue management unit 23 can determine the type of issue depending on the topic of the workflow (in the embodiment, the topic of the administrative object group associated with the workflow). When a workflow of a specific topic is started, the issue management unit 23 can register an issue to which an input form for one or more specified data items is linked and assign it to a responsible person. In this case, the responsible person can display the issue information to which the input form is linked.
[0082] Here, if a completion operation by another person in charge is required, the process waits for the completion operation by the other person in charge. When the completion operation by all necessary persons has been performed (see S508 in FIG. 5), stage WS1 (see S509 in FIG. 5) is completed. If all stages N included in the workflow have not been completed (see S510 in FIG. 5), the next stage is executed (see S511 in FIG. 5). When all stages N included in the workflow have been completed (see S510 in FIG. 6), the workflow is terminated (see S512 in FIG. 5).
[0083] FIG. 6(b) is an example of the screen display of the administrative business group list screen. The administrative business group list screen W6b displays the workflow processing status compiled by the workflow management unit 25. In the illustrated example, if the workflow has four stages, the stage at which each issue in the administrative business group has progressed is compiled and displayed. In the illustrated example (group name: 2023 Budget Preparation), the issue group contains 17 issues, of which 15 have progressed to the first stage and 2 have progressed to the second stage. Note that here, the workflow management unit 25 compiles the number of issues by stage, but it may also compile any data item, such as the budget amount for the administrative business corresponding to the issue, and display the results by stage.
[0084] <4.2. Example of workflow progress> A specific example of a workflow will be described with reference to Figure 7. Figure 7 shows an example of the progress of a workflow related to a budget preparation topic. First, the person in charge of the secretariat department starts a workflow for the task group for which the budget preparation topic is set, with the department manager, finance section manager A, finance section manager B, and the head of the local government as the task managers. This assigns issues to each task manager and first requests the department manager to prepare budget requests for each task and project belonging to the task group (see Figure 7WS1). The department manager, who has been requested to prepare the budget requests, assigns multiple department managers, including department manager A, to the task group and divides and assigns the issues (see Figure 7WS2). The division of issues is automatically assigned by the issue management unit 23, for example, by referencing the information of the person in charge (the person responsible for creating the issues) registered in the task and project information. The multiple department managers, including department manager A, to whom the issues have been assigned, create budget requests by entering specified data items related to the task and project information, and submit them for appraisal by the department manager, starting with the issues for which budget requests have been completed (see Figure 7WS3).
[0085] The original department manager receives assignments for all issues in the issue group from multiple original department staff members, including original department staff member A, and once the assessments are complete, he performs a budget request submission operation. This transfers authority for all issues in the issue group to finance department staff member A, who was previously set as the person in charge, and a project assessment is performed (see Figure 7WS4). Once finance department staff member A completes the project request assessment, he performs a request to create a project budget proposal. This transfers authority for all issues in the issue group to finance department staff member B, who was previously set as the person in charge, and a request is made to create a project budget proposal (see Figure 7WS5). Once finance department staff member B completes the creation of the project budget proposal, he performs a request to create a project budget proposal. This transfers authority for all issues in the issue group to the head of the local government, who was previously set as the person in charge, and a request is made to assess the budget proposal (see Figure 7WS6). Once the budget proposal assessment is complete, the head of the local government performs a budget proposal assessment completion operation. This ends the workflow, and a notification is sent to the person in the secretariat department who started the workflow. [Explanation of symbols]
[0086] 1. Administrative Management System 2 Administrative management device 21 Administrative Object Management Department 22 Administrative Objects Group Management Department 23 Issue Management Department 24 Issue Group Management Department 25 Workflow Management Department 3. User terminal
Claims
[Claim 1] An administrative management system that performs object-oriented workflow management, storing administrative data having a plurality of types of data items and registered for each administrative object; An administrative management system that creates issues associated with individual administrative objects based on designated topics and administrative objects, and determines the processing status of a workflow in the topic using the processing status related to the issues.
Citation Information
Patent Citations
Administrative management supporting method, administrative management supporting program for making computer execute the method and administrative management supporting system
JP2005293321A