Determination assistance system, determination assistance method, and determination assistance program

Abstract

This invention provides know-how necessary for making an administrative determination, and thereby assists with making the determination.　Policy system information, which is related to a policy system including policies, measures, and administrative work, and associated information, which is associated with the policy system information, are registered. Determination know-how, which indicates a suggestion or a result of a determination with respect to the policy system, is linked with at least the associated information and stored in a database. In response to a determination assistance request, which includes at least the associated information of target policy system information that requires determination assistance, the database is referenced to generate determination assistance information which includes the determination know-how corresponding to the associated information included in the determination assistance request.

Description

Decision support system, decision support method, decision support program

[0001] The present invention relates to a decision support system, a decision support method, and a decision support program for supporting decisions in government administration.

[0002] In administrative organizations, including local governments, the finance department is primarily responsible for making various decisions regarding policy systems, including policies, measures, and administrative projects. These decisions must be made comprehensively, taking into account the various circumstances and factors that arise in the policy system, which has led to the problem of high costs.

[0003] Patent Document 1 discloses a technology that aims to solve the problem of local government financial planning being carried out from a macro perspective, while budget assessments for individual administrative projects are carried out from a micro perspective, and that the two are not linked. The technology makes it possible to maintain consistency between individual plans and overall strategies by making the creation of revenue and expenditure plans for individual administrative projects rules, making them more detailed, and implementing IT, 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.

[0004] Furthermore, Patent Document 1 discloses technology aimed at simplifying the processes of financial departments involved in budget assessments and administrative reform plans, and at realizing budget assessments and long-term financial estimates that are in line with the actual state of administrative projects. Patent Document 1 discloses methods for conducting budget assessments while understanding the fiscal balance, determining the appropriateness of the fiscal balance in conjunction with the budget assessment, preparing a budget revision proposal, and further understanding the fiscal balance after the budget assessment using the revision proposal. Patent Document 1 also discloses preparing a revision proposal for the abolition, postponement, or budget reduction of some projects while referring to various data on the administrative project sheet 133 (e.g., indicators indicating necessity, contribution to higher-level objectives, urgency, appropriateness of scale, etc.).

[0005] Japanese Patent Application Laid-Open No. 2005-293321

[0006] When the Finance Division makes decisions about individual tasks and projects, it needs to refer to various data for each task and project. The Finance Division reviews this data, considering the specific circumstances and situations, and makes a final decision based on past experience and know-how. However, the circumstances and know-how required for each task and project are diverse and complex, and there is no clear definition of these. This has led to issues such as the cost of making decisions and the dependency on individual skills.

[0007] In view of the above-mentioned problems, the present invention aims to provide a technology that supports administrative decisions by providing know-how necessary for such decisions.

[0008] [1] A decision support system for supporting administrative decisions, the system registers policy system information relating to a policy system including policies, measures, and administrative projects, and associated information associated with the policy system information, stores decision know-how indicating suggestions or results of decisions on the policy system in a database, linked to at least the associated information, and references the database in response to a decision support request including at least the associated information of target policy system information requiring decision support, and generates decision support information including the decision know-how corresponding to the associated information included in the decision support request. [2] The database stores the decision know-how linked to a combination of a policy system tag indicating a classification of the policy system and the associated information, and references the database in response to a decision support request including the policy system tag and the associated information of the target policy system information, and generates decision support information including the decision know-how corresponding to the combination of the policy system tag and the associated information included in the decision support request. [3] The decision support system according to [1] or [2], wherein the decision know-how includes a decision axis tag or a decision viewpoint and a correction rate for a value of a decision subject, and refers to the database in response to a decision support request including at least accompanying information of the target policy system information, and generates decision support information including the decision axis tag or the decision viewpoint corresponding to the accompanying information included in the decision support request and the correction rate. [4] The decision support system according to [3], wherein the decision axis tag or the decision viewpoint included in the decision support information and the corresponding correction rate are applied to the value of the judgment subject of the target policy system information to obtain a correction value. [5] The decision support system according to [3], wherein a plurality of decision axis tags or the judgment viewpoints corresponding to accompanying information included in the decision support request and a plurality of corresponding correction rates are obtained, and the decision support information includes an average correction rate obtained by averaging the plurality of correction rates.[6] The decision support system according to any of [1] to [5], wherein the judgment know-how includes assessment know-how having a perspective on assessment for a budget and assessment axis tags, the associated information includes budget item items which are classifications of budget items, the database stores the assessment know-how linked to combinations of policy item tags which indicate classifications for the policy system and the budget item item, and in response to a decision support request including the policy item tag of the target policy system information and the budget item item, references the database and generates decision support information including the assessment know-how corresponding to the combination of the policy item tag and the budget item item included in the decision support request. [7] The decision support system according to [6], wherein the assessment know-how further includes an assessment rate, and in response to a decision support request further including a budget request amount of the target policy system information, generates decision support information including the assessment rate related to the assessment axis tags, and obtains the assessment amount of the target policy system information by applying the assessment rate related to the assessment axis tags to the requested amount. [8] The decision support system described in [6] or [7], which stores assessment know-how including assessment amounts in a database linked to the policy system tags and budget item system items of the target policy system information. [9] The database stores budget item system items, policy system tags indicating policy system classifications, budget amounts, and organizational system items in linked relation to each other, and in response to a decision support request including the policy system tag of the target policy system information, compares and displays the budget amounts for each budget item system item in the policy system related to the policy system tag of other organizational system items.

[10] A decision support system described in any of [1] to [9], wherein the judgment know-how includes special fund know-how having a funding source tag indicating a specific funding source, the accompanying information includes budget item system items which are classifications of budget items, the database stores the special fund know-how linked to combinations of policy system tags indicating classifications for the policy system and the budget item system items, and in response to a decision support request including the policy system tag and budget item system items of the target policy system information, references the database and generates decision support information including the special fund know-how corresponding to the combination of policy system tag and budget item system items included in the decision support request.

[11] A decision support system described in any of [1] to

[10] , wherein the judgment know-how includes classification know-how having subject tags related to local government financial situation surveys or public accounting, the accompanying information includes budget subject system items which are classifications of budget subjects, the database stores the classification know-how linked to combinations of policy system tags which indicate classifications for the policy system and the budget subject system items, and in response to a decision support request including the policy system tags and budget subject system items of the target policy system information, references the database and generates decision support information including the classification know-how corresponding to the combination of policy system tags and budget subject system items included in the decision support request.

[12] A decision support system described in any of [1] to

[11] , wherein the judgment know-how includes proposed know-how having an index tag related to an administrative goal system item, the accompanying information includes a budget item system item which is a classification of a budget item, the database stores the proposed know-how linked to a combination of a policy system tag indicating a classification for the policy system and the budget item system item, and in response to a decision support request including a policy system tag and a budget item system item of the target policy system information, references the database and generates decision support information including the proposed know-how corresponding to the combination of the policy system tag and the budget item system item included in the decision support request.

[13] A decision support system described in any of [1] to

[12] , wherein the judgment know-how includes proposal know-how having an alliance tag related to an alliance of the policy system, the accompanying information includes budget item system items which are classifications of budget items, the database stores the alliance tags linked to combinations of policy system tags and budget item system items which indicate classifications for the policy system, and refers to the database in response to a decision support request including the policy system tag and budget item system items of the target policy system information, and generates decision support information including the proposal know-how corresponding to the combination of policy system tag and budget item system items included in the decision support request.

[14] A decision support system for supporting administrative decisions, comprising: registering policy system information on a policy system including policies, measures, and administrative projects, and accompanying information associated with the policy system information, having a decision model that outputs decision know-how indicating suggestions or results of decisions for the policy system in response to input of the accompanying information, and in response to a decision support request including at least the accompanying information of target policy system information requiring decision support, inputting the accompanying information into the decision model, and generating decision support information output from the decision model, including the decision know-how.

[15] A decision support method for supporting administrative decisions, comprising: registering policy system information on a policy system including policies, measures, and administrative projects, and accompanying information associated with the policy system information, linking decision know-how indicating suggestions or results of decisions for the policy system to at least the accompanying information and storing it in a database, and in response to a decision support request including at least the accompanying information of target policy system information requiring decision support, referring to the database, and generating decision support information including the decision know-how corresponding to the accompanying information included in the decision support request.

[16] A decision support program that supports decisions in administration, the decision support program causing a computer to function to execute the following process: registering policy system information relating to a policy system including policies, measures, and administrative projects, and accompanying information associated with the policy system information; storing decision know-how indicating the implications or results of decisions on the policy system in a database, linked to at least the accompanying information; and referencing the database in response to a decision support request including at least the accompanying information of target policy system information requiring decision support, and generating decision support information including the decision know-how corresponding to the accompanying information included in the decision support request.

[0009] The invention according to [1] can provide decision-making know-how for policy systems that require decision-making support.

[0010] The invention according to [2] can provide more accurate decision-making know-how to policy systems that require decision-making support.

[0011] The invention according to [3] can provide a correction rate for a value of a certain judgment subject as judgment know-how. The invention according to [4] can provide a correction value for a value of a judgment subject. The invention according to [5] can provide an average correction rate of a value that is a judgment subject.

[0012] The invention according to [6] can provide assessment know-how for policy systems that require judgment support, and can support assessment decisions.

[0013] The invention according to [7] makes it possible to provide an appraisal amount and assist in making an appraisal decision.

[0014] The invention according to [8] makes it possible to update assessment know-how and utilize it for assessment judgments of other policy systems.

[0015] The invention according to [9] can assist in assessment decisions by comparing the budget levels of other local governments.

[0016] The invention according to

[10] can provide know-how on specific financial resources of a policy system that requires decision support, and can support assessment decisions regarding financial resources.

[0017] The invention according to

[11] provides classification know-how for policy systems that require judgment support, and can support classification judgments for accounting subjects.

[0018] The invention according to

[12] makes it possible to provide proposal know-how relating to indicators of administrative goals of policy systems that require decision support, and to provide proposal support relating to indicators.

[0019] The invention according to

[13] provides proposal know-how relating to collaboration in a policy system that requires decision support, and makes it possible to provide proposal support for business entities and businesses that can collaborate with the policy system.

[0020] The invention according to

[14] makes it possible to provide judgment know-how for a policy system that requires judgment support using a judgment model.

[0021] According to the present invention, it is possible to provide a technology for supporting decisions by providing know-how necessary for administrative decisions.

[0022] Block diagram of the system of this embodiment. Hardware configuration diagram of this embodiment. Outline explanatory diagram of policy system tags of this embodiment. Outline explanatory diagram of classification of judgment axis tags of this current form. Outline explanatory diagram of decision support of this embodiment. Data configuration example of administrative business information and detailed business information. Data configuration example of judgment know-how data of this embodiment. Configuration example of classification model of this embodiment. Display example of assessment screen of this embodiment. Different data configuration example of judgment know-how data of this embodiment. Display example of budget reference screen of this embodiment. Display example of proposal screen of this embodiment.

[0023] Hereinafter, a decision support system, a decision support method, and a decision support program according to embodiments of the present invention will be described with reference to the accompanying drawings. Note that the embodiments shown below are merely examples of the present invention, and the present invention is not limited to the following embodiments, and various configurations can be adopted.

[0024] In this embodiment, the configuration, operation, etc. of a decision support system and a decision support device are described, but a decision support method, a computer program, and a program recording medium on which the program is recorded, each having a similar configuration, also achieve the same effects. For example, by using a program recording medium, the program can be installed on a computer. 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 a flexible disk, or even via a communication line.

[0025] The decision support system is configured by a computer device. The computer device has an arithmetic unit such as a CPU (Central Processing Unit) and a storage device. The computer device can function as a decision support device by executing a decision support program stored in the storage device using the arithmetic unit. The decision support method is realized by processing of the computer device including the decision support device.

[0026] The decision support system is used in administrative organizations to manage administrative activities. Administrative organizations are organizations that manage administration, including government agencies, ministries, public organizations, etc., such as national and local governments, and in this embodiment, local governments are used as an example. The decision support system is particularly used in the financial departments of administrative organizations to support various administrative decisions in administrative activities.

[0027] 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, and public organizations, such as national and local governments. In embodiment 1, a local government is used as an example. The decision support system according to the present invention is used in administrative organizations to operate and manage administrative activities. A policy system is a system of issues divided into three levels: policies, measures, and administrative projects. For example, a division into four or more levels may be used to manage administrative projects, with a level of sub-measures between measures and administrative projects. A policy is a broad group of administrative activities aimed at realizing basic guidelines for addressing specific administrative issues, and indicates the direction and objectives of urban development in an established administrative division (such as a city, ward, town, or village). A policy is a group of administrative activities aimed at realizing specific guidelines based on the basic guidelines of a policy, and indicates the measures and countermeasures for realizing the policy. An administrative project is an administrative project or project that serves as an individual administrative means for realizing the specific policies of a policy. Tasks and projects are implemented by each bureau within an administrative division based on its own budget. In this embodiment, the task system is divided into four levels, with each task and project being further broken down into one or more sub-projects. Sub-projects are specific divisions of tasks and projects as administrative measures related to a task and project.

[0028] An administrative object refers to an object handled in administrative activities. In this embodiment, individual administrative tasks and projects are managed as administrative objects. However, for example, answers to questions from assembly members and committee responses prepared by executive bodies such as administrative agencies, the planning, execution, and evaluation stages of administrative tasks and projects, and issues collected by assemblies, committees, etc. and that serve as the basis for formulating administrative issues for the next term and beyond may also be treated as administrative objects. Furthermore, if the administrative organization is the national government, projects including direct projects and affiliated organization projects, as well as other general objects of administrative activities, may be treated as administrative objects. Administrative objects are managed as administrative data in database 4.

[0029] Administrative judgments are judgments made in administrative activities related to policy systems. Administrative judgments include assessment judgments, classification judgments, proposal judgments, etc. Assessment judgments include judgments that determine the assessed amount for the requested amount estimated at the request stage of budget formulation, and judgments that determine the financial resources and amounts to be allocated as budgets. Classification judgments include judgments that appropriately classify various information and items related to policy systems. Proposal judgments include judgments that propose goals, etc. for improving administrative activities related to policy systems. Assessment judgments also encompass pre-announcement judgments that determine the pre-announcement amount for the assessed amount assessed at the assessment stage of budget formulation.

[0030] <1.2. Overview of administrative activities> Here is an example of the flow of administrative activities in a local government. First, in the planning stage, plans for the tasks and projects to be implemented in the next execution year (for example, the following fiscal year) are prepared. Next, in the budget compilation stage, budget requests for the tasks and projects to be implemented in the next execution year are prepared, the budget requests are assessed, a budget proposal is prepared, and the proposal is submitted to the assembly. Then, in the execution year, in the execution stage, the budget is executed for the tasks and projects approved by the assembly. In the evaluation stage, an administrative evaluation report is prepared for the tasks and projects that have been executed.

[0031] 1.3. Definition of Terms, etc. 2. A topic refers to a gradual division of administrative activities carried out with an administrative object as the target. One or more topics may be defined for each type of administrative object. In this embodiment, for example, when an administrative project is the target, multiple chronological divisions such as "Budget Preparation > Request," "Budget Preparation > Assessment," "Budget Preparation > Preliminary Notification," "Budget Preparation > Resolution," "Budget Execution," "Settlement of Accounts," and "Administrative Evaluation" are defined as topics. The above is an example, and different divisions, abstract divisions, and more detailed divisions may be defined. Furthermore, topic divisions may be hierarchically organized into multiple layers. For example, instead of the topic "Budget Preparation > XX," divisions such as "Initial Budget Preparation (hereinafter referred to as "Initial") > XX" and "Supplementary Budget Preparation (hereinafter referred to as "Supplementary") > XX" may be defined. Furthermore, subtopics such as "Initial Budget Preparation (hereinafter referred to as "XX")" and "Supplementary Budget Preparation (hereinafter referred to as "XX")" may be defined in a layer below "Budget Preparation." Furthermore, multiple chronological divisions may also be defined in the lower layers. For example, categories such as "request," "assessment," "unofficial notice," and "resolution" may be defined in the layer below "budget compilation."

[0032] 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.

[0033] A workflow refers to a repeatable, defined flow of administrative activities. In this embodiment, the workflow includes multiple stages WS executed to achieve a certain purpose, and progresses by completing issues assigned to individuals in each stage WSn. The stages of a workflow executed in a certain topic can be understood as smaller stages of administrative activities related to that topic.

[0034] Data items are various data that are registered and managed regarding administrative objects. Mandatory data items are a category of data items that must be registered. Optional data items are a category of data items that have predefined attribute names and allow data values ​​to be entered or the entered data items to be displayed by enabling or disabling them. Additional data items are a category of data items that allow data values ​​to be entered or the entered data items to be displayed by registering unique attribute names.

[0035] Judgment know-how provides suggestions or results for administrative decisions regarding a certain judgment subject of an administrative object. Judgment subjects in this embodiment include, but are not limited to, budgets, financial resources, items, indicators, etc., and can include various judgment subjects necessary for administrative work. Judgment know-how includes judgment perspectives that provide suggestions for administrative decisions. Judgment perspectives refer to perspectives considered when making administrative decisions (decisions) regarding a certain judgment subject of an administrative object. Judgment know-how includes judgment axes that provide results for administrative decisions. Judgment axes refer to more specific judgment axes or grounds derived from consideration based on judgment perspectives. Judgment axes can also be the conclusions of judgment subjects that can derive explicit conclusions. Judgment axes can also be derived directly from judgment subjects without using judgment perspectives. In administrative decisions, judgment axes and judgment results are derived through consideration based on judgment perspectives. Therefore, judgment axes can be grouped by judgment perspective.

[0036] Assessment judgment includes assessment perspectives as a point of view, and the subject of judgment, such as the budget and financial resources, is assessed according to that assessment perspective. Classification judgment includes classification perspectives as a point of view, and the subjects and items of judgment are classified according to that classification perspective. Proposal judgment includes proposal perspectives as a point of view, and indicators of the subject of judgment, such as goals, are proposed according to the proposal perspective. It is also possible to derive judgment axes without including judgment perspectives. As a specific example, if the subject of judgment is "budget," the "judgment perspective" of "Is the budget request amount appropriate?" is examined. If the result of this examination is that the requested amount is the same as the previous year, the judgment axis of "same as previous year" is derived, and an assessment is made according to that judgment axis. In this case, if the judgment axis is the same as the previous year, it is determined that no adjustments to the requested amount are necessary, and the assessment is made according to that policy. As a specific example, if "subject" is the subject of judgment, the judgment axis will be how to classify a certain accounting subject (item / item subsection) in local government finances into subjects or items corresponding to the accounting type, such as financial settlement statistics (local government financial status survey items) or public accounting. As a specific example, if "indicator" is the subject of judgment, an examination will be conducted to determine what kind of budget was spent on what kind of task or project based on the content of the task or project and the budget subjects. Then, as a result of this examination, the judgment axis will be determined to determine what kind of target indicator will improve with budget execution. Target indicators indicate items that can be evaluated quantitatively, such as KPIs. For example, if a budget with the subject "subsidies" is spent on a "project to combat declining birthrate," indicators such as "number of grant applications" and "number of births" will be obtained.

[0037] 1 shows a system configuration diagram of a decision support system 1. As shown in Fig. 1, the decision support system 1 includes a decision support device 2, a user terminal 3, and a database 4, and each component is connected to a communication network NW. For example, the communication network NW includes a local government wide area network (LGWAN), and the decision support device 2 and the database 4, and the decision support device 2 and the user terminal 3 are connected via the comprehensive government network.

[0038] The decision support system 1 (decision support device 2) provides a platform for operating and managing administrative activities related to administrative objects including at least administrative projects. The decision support device 2 provides information on the platform to support administrative decisions regarding administrative activities including administrative projects. The decision support device 2 includes, as functional components, an administrative data management unit 21, a tag processing unit 23, a generation unit 24, an output unit 27, and a setting management unit 28.

[0039] The user terminal 3 is a terminal device used by users belonging to an administrative organization, etc. A plurality of user terminals 3 are installed at least within the administrative organization.

[0040] 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, the Civil Engineering Department (bureau / section) and the Agriculture, Forestry and Fisheries Department (bureau / section), and users and supervisors (section chiefs, department heads, etc.) of original bureaus and original sections. For example, original section users perform tasks such as creating project documents such as business plans, creating budget requests, budget execution, and creating administrative evaluation reports. Finance section users perform tasks such as assessing budget requests created by original section users, journalizing accounting entries for local government financial status surveys, and making judgments on indicators (goals) for business projects and proposing improvements to those indicators based on their performance. Secretariat users perform tasks such as requesting original section users to prepare budget requests and evaluating budget requests. Section chiefs, department heads, and special officials perform tasks such as reviewing users' deliverables, selecting and prioritizing priority projects based on plans, and assessing budget requests approved by the Finance Division users. The decision support system 1 provides each user with a predetermined operation authority, and controls permission and restriction of predetermined functions according to the operation authority.

[0041] 2.2. Hardware Configuration Fig. 2(a) shows a hardware configuration diagram of the judgment support device 2. The judgment support device 2 includes a control unit 201, a storage unit 202, and a communication unit 203 as its hardware configuration. In this embodiment, the judgment support device 2 can be a computer device such as a server or a personal computer. Note that the judgment support device 2 may be configured using multiple computer devices, and is not limited to the configuration shown in Fig. 2(a) as long as the above-described functional components (21-26) can be realized as a whole.

[0042] The control unit 201 is configured with one or more processors such as a CPU, and controls the overall processing of the decision support device 2 by executing a decision support program, an operating system (OS), and other applications. The storage unit 202 is configured with one or more memories such as a hard disk drive (HDD), a solid state drive (SSD), a flash memory, or a random access memory (RAM), and stores the decision support 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 4. The control unit 201 executes the decision support program to cause the computer to function as the decision support device 2 and execute the decision support method.

[0043] In the illustrated example, the database 4 is a database server that can be accessed via a communication network NW including an LGWAN, etc., but it may also be realized using, for example, the control unit 201 and memory unit 202 that constitute the judgment support device 2, or it may be connected to the judgment support device 2 via a LAN, etc.

[0044] In this embodiment, the database 4 has a judgment know-how DB 40 that stores judgment know-how data. The judgment know-how DB 40 has an appraisal know-how DB 41, a special assets know-how DB 42, a classification know-how DB 43, and a proposal know-how DB 44, which correspond to judgment subjects. The database 4 also has a specific financial resources DB 45 that stores financial resource information.

[0045] 2B 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.

[0046] 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 judgment support device 2. The input unit 904 is an input interface that accepts operation requests from an operator, and is composed of at least one of a touch panel, a mouse, a keyboard, etc. The display unit 905 is composed of a display that displays processing results by the control unit 901, etc.

[0047] 2.3. Output Unit The output unit 27 displays the administrative data management platform on the user terminal 3. The administrative data management platform is used for registering, editing, and deleting various types of data (hereinafter referred to as "registration"), as well as for workflow management, data display, and data output, based on requests from the user terminal 3. In this embodiment, the management platform is used in the form of a web browser application. Users use their own accounts to use the management platform, and the information processing described below is executed via the management platform.

[0048] 3.1. Data Structure First, the data structure in the decision support system according to this embodiment will be described.

[0049] The database 4 stores organizational master data, user master data, policy and measure master data, subject master data, administrative goal master data, and authority master data, as well as administrative business information (administrative data) from previous years.

[0050] The organizational master stores organizational structure items that represent a tree-structured organizational structure by linking data items as master data for data items related to organizations within or outside the administrative organization. In this embodiment, the organizational master stores organizational information and department information as organizational structure items. The organizational information stores identification information (organization ID) of the organization and the organization name. The department information stores identification information (department ID) of the department (division, section, office, etc.) within the organization, identification information (organization ID) of the organization to which the department belongs, identification information (department ID) of the higher-level department to which the department belongs, and the department name. The departments to which users belong, as described below, and departments in charge of policies, measures, and administrative projects, etc., are registered in an identifiable manner based on the organizational structure items. The user master stores user information within the organization. The user information includes user identification information (user ID), name, department (organization structure item), etc. Note that user groups, which are a collection of one or more users, may be defined. The user group information may be predefined by, for example, the identification information of the user group (user group ID) and the identification information of the users belonging to the user group, or users having a common attribute such as an organizational structure item may be treated as a user group. The users to be included in the predefined user group may be arbitrarily selectable, or may be selectable from user groups having a common attribute. The user group is specified by an arbitrarily set group name or an attribute name that represents the characteristics of the group.

[0051] The policy / measure master stores policy / measure system items that represent a tree-structured policy / measure system by linking data items as master data for data items related to policies and measures. In this embodiment, the policy / measure master stores policy information and measure information as policy / measure system items. The policy information / measure information includes identification information for the policy / measure (policy ID / measure ID), policy number / measure number, policy name / measure name, responsible department (department, section, etc.), policy purpose / measure purpose, and policy summary / measure summary. Furthermore, the measure information includes identification information for the corresponding main policy (policy ID).

[0052] The item master stores master data for data items representing item system items. In this embodiment, as master data for data items representing the budget item system and the local government financial status survey item system, budget item system items representing the tree-structured budget item system through linkages between data items and local government financial status survey items representing the tree-structured local government financial status survey item system are stored. In this embodiment, the budget item master stores budget item information as budget item system items. The budget item information includes budget item identification information (budget item ID), identification information (budget item ID) of the higher-level budget item to which the budget item belongs, budget item type (in this embodiment, either a subitem, section, or subitem), and budget item name. The budget item type includes subitems (higher-level budget items), which are higher-level items corresponding to the objectives at the time of closing, and subitems (lower-level budget items), which are lower-level items corresponding to the characteristics. When the administrative organization is a national government, items, etc., can be higher-level budget items, and items under the items can be lower-level budget items. The local government financial situation survey item master stores expenditure breakdown purpose information and budget property information as local government financial situation survey items. The expenditure breakdown purpose indicates the purpose of expenditure linked to an administrative project and is used for local government financial situation surveys in the settlement topic. The expenditure breakdown purpose information includes identification information of the expenditure breakdown purpose (expenditure breakdown purpose ID), identification information of the higher-level expenditure breakdown purpose to which the expenditure breakdown purpose belongs (expenditure breakdown purpose ID), identification information of the corresponding budget item (any of the subitems) (budget item ID), type of expenditure breakdown purpose (in this embodiment, there are three types: major classification, medium classification, and minor classification), and expenditure breakdown purpose name. The budget property indicates the property of the budget set under a section or subsection, and the budget property information includes identification information of the budget property (budget property ID), identification information of the higher-level budget property (budget property ID), identification information of the budget item (section or subsection) to which the budget property belongs (corresponds to) (budget item ID), type of budget property (in this embodiment, there are four types: major classification, medium classification, minor classification, and detailed classification), and budget property name.

[0053] The administrative goal master stores administrative goal system items that represent the administrative goal system in a tree structure by linking data items as master data for data items that represent the administrative goal system. Administrative goals define KPIs for achieving each task or project, i.e., tasks to be achieved during the execution period of the task or project. One or more administrative goals are set for each policy, measure, and task or project, and are structured hierarchically in accordance with the higher-level policy and measure system. In this embodiment, the administrative goal master stores administrative goal information as administrative goal system items. The administrative goal information includes identification information for the administrative goal (administrative goal ID), identification information for the policy, measure, or task or project to which the administrative goal system item is linked, the content of the administrative goal, the deadline for achieving the administrative goal, and actual results for the administrative goal.

[0054] 3.2. Master Data Registration The setting management unit 28 accepts input related to organizational information, department information, user information, policy information, measure information, budget item information, expenditure breakdown purpose information, budget nature information, and administrative goal information from the user terminal 3, and registers the information in the database 4.

[0055] 3.3. Registration of business information Next, the registration of business information in the decision support system according to this embodiment will be described.

[0056] For each task and project, the budget amount, itemized items (budget item system items) used during execution and associated with expenditure amounts, and the expenditure breakdown purpose and budget nature (local government financial status survey items) used during settlement and used to prepare the local government financial status survey are associated from the budget request stage. In addition, for each task and project, breakdown items are set, which are elements that can be decomposed and are contained within each task and project, such as administrative activities related to the task and project, expenditure items related to the budget's use, and budget funding sources. As breakdown items, one or more subprojects are linked to a task and project to which a subproject (budget item system item) is associated. Individual expenditure items indicating the purpose and destination of the budget expenditure to which the subproject (budget item system item) is associated are linked. Individual expenditure items include estimate items indicating the budget amount, etc., and a funding breakdown indicating the funding source. Furthermore, individual tasks, projects, minor projects, or individual expense items are linked to organizational system items, policy and program system items, item categories, and administrative goal system items. In this embodiment, a data structure is adopted in which tasks, projects, and budget item categories (higher-level budget items) related to sub-items are linked to one or more organizational system items, one or more policy and program system items, one or more administrative goal system items, and individual expense items, which are the breakdown items of the tasks, are linked to budget item categories (lower-level budget items) related to the sub-items. Furthermore, in any topic, labels indicating their contents may be assigned to individual tasks, minor projects, or individual expense items. In this embodiment, a label indicating that a task is a priority project is assigned to a task, and a label indicating that a mandatory expense or a label indicating an increase or decrease in the budget amount for an ongoing project, etc. is assigned to an individual expense item.

[0057] The administrative business information is administrative data related to each administrative business, and is registered for each execution year. In this embodiment, the administrative business information includes basic information related to the administrative business (basic administrative business information), administrative goal information, budget information, financial resource information, and expenditure and income information related to the administrative business. Basic information on administrative projects (basic administrative project information) is information on the content of administrative projects, and includes the basic information's (i.e., administrative project information) identification information (administrative project ID), related administrative data, administrative project name, major policies and measures to which the administrative project belongs (policy and measure system item), project start year, execution (planned) year, budget category (initial budget, supplementary budget number), topic, budget amount for the administrative project, revenue amount for the administrative project, budget name, affiliated bureau / agency (organizational system item), responsible department (organizational system item), accounting category, administrative project status (e.g., "new," "expansion," "reduction," "suspended," "abolished"), section item (higher-level budget item: budget project system item), major classification, medium classification, minor classification of expenditure breakdown purpose (local government financial situation survey item), expense classification, budget amount for the administrative project, etc., as well as optional items such as administrative project purpose, administrative project overview, underlying laws and regulations, related plans and notifications, current situation and issues, project (planned) completion year, remarks, priority issues (administrative goal system item), and zero, one, or multiple additional data items.

[0058] Budget information includes, for example, budget amounts for each topic (e.g., "Budget Preparation > Request," "Budget Preparation > Assessment," "Budget Preparation > Preliminary Notification / Resolution"), individual expense item names, and subdivisions of expense items (budget item system items), as well as major, medium, minor, and detailed budget classifications (local government financial situation survey items). Budget amounts include the requested amount, which is the budget amount estimated at the "request" stage of budget preparation; the assessed amount, which is the budget amount adjusted as necessary from the requested amount at the "assessment" stage; the preliminarily announced budget amount, etc. In this embodiment, each administrative and business information is configured to hold the budget amounts for each stage for each individual expense item it has. Funding information indicates one or more funding sources for each budget amount, and includes, for example, the name of the funding source, the amount of revenue appropriated for the budget information, and subdivisions (budget item system items). For example, revenue amounts are linked to each topic in the same way as budget amounts, and are configured to be able to hold, for example, the revenue request amount, which is the estimated revenue amount at the ``request'' stage of budget preparation, the revenue assessment amount, which is the revenue amount adjusted as necessary from the revenue request amount at the ``assessment'' stage, and the revenue indication amount, which is the ``indicated'' revenue amount.

[0059] In this embodiment, administrative projects are broken down into a four-level tree structure based on the breakdown items (administrative project > minor project > individual expense item > accumulated item). An administrative project has a structure that includes one or more minor projects, and a minor project includes one or more individual expense items. Administrative project information includes administrative project basic information, which is a data item in the administrative project layer that represents the content of the administrative project; minor project information, which is a data item in the minor project layer that represents the content of the minor project; and data items in the individual expense item layer that represent the content of the individual expense item. One or more accumulated items are included in individual expense items, and are registered using accumulated item information that indicates the budget amount for the administrative project or a higher-level breakdown item by being accumulated. Funding breakdowns are included in individual expense items (0 or 1), and are registered using funding breakdown information that indicates the revenue amount for the administrative project or a higher-level breakdown item.

[0060] The minor project information includes various information related to the minor project, such as identification information for the minor project (minor project ID), identification information for related administrative information (administrative project ID), minor project name, minor project overview, minor project status (e.g., "new," "expansion," "reduction," "suspended," "cancelled"), and budget amount for the minor project.

[0061] Individual expense items indicate expense items required for administrative activities related to the corresponding subprojects, and individual expense item information includes identification information for the individual expense item (individual expense item ID), identification information for the related subprojects (subproject ID), individual expense item name, budget amount for the individual expense item, individual expense item group label, individual expense item summary, subsections (sub-budget items: budget item system items), and properties (budget properties: budget item system items). Total items are specific expense items included in individual expense items, and total item information includes identification information for the total item (total item ID), identification information for the related individual expense items (individual expense item ID), total item name, budget amount for each topic, planned execution quarter, total item summary, and total basis (formula, etc.). The funding breakdown indicates the funding source for each individual expenditure item, and funding information includes funding identification information (funding ID), identification information for the related individual expenditure item (individual expenditure item ID), funding name, revenue amount for each topic, funding allocation rate, funding classification, item subsection (budget item: budget item system item), responsible department (organization system item), allocation basis, and allocation reason. In this embodiment, funding information is registered as a funding breakdown for specific funding sources. For one individual expenditure item, if the entire budget amount is covered by general funding sources, no funding information is registered, and if the amount is covered by specific funding sources, or specific funding sources and general funding sources, one piece of funding information is registered. The funding breakdown for general funding sources can be obtained from the difference between the budget amount and the revenue amount, or the budget amount and the funding allocation rate.

[0062] Based on individual expenditure items, or individual expenditure items and estimated items, the details of each task and project can be set from the budget preparation stage. In the execution process described below, the budget item system items and / or local government financial status survey items for this task and project can be specified to execute the budget, eliminating the need to reconcile the budget and expenditures at the settlement stage. The expenditure breakdown purpose and budget nature are items that correspond to higher-level budget items and lower-level budget items, respectively. However, even when the administrative organization is the national government, financial-related items that correspond to higher-level budget items and lower-level budget items can be set as master data and associated with projects and individual expenditure items.

[0063] In this embodiment, the administrative business is subdivided into a four-level tree structure, and the budget amount for an administrative business is determined by the total budget amount of the sub-businesses under the administrative business, the budget amount for a sub-business is determined by the total budget amount of the individual expense items under the sub-business, and the budget amount for an individual expense item is determined by the total budget amount of the accumulated items under the individual expense items. In other words, when registering administrative business information, the administrative data management unit 21 registers the budget amount for the accumulated items, thereby also registering the budget amounts for the individual expense items, sub-businesses, and administrative business. The same applies to revenue amounts.

[0064] 3.4. Data Structure of Tag Information Tag information is stored in the database 4. In this embodiment, the tag information includes a policy system tag and a judgment axis tag.

[0065] Policy system tags indicate the classification of policy systems, including at least policies, measures, administrative projects, and minor projects. Policy system tags are used to define the classification of policy systems within each administrative organization. For example, administrative projects related to child-rearing support are managed under a variety of names, such as child-rearing support app projects, childbirth support grants, and playground equipment maintenance and inspections, making it difficult to distinguish at a glance what kind of administrative project they are. By assigning policy system tags with a unified definition to such administrative projects, management and operation can be made more efficient.

[0066] The policy system tag includes, as data items, a tag ID, a tag name, a granularity level, and a relation tag ID. The policy system tag has a tree structure based on the granularity level (policy system type).

[0067] The granularity level indicates which policy system type the tag is, such as policy, measure, or administrative / business. The granularity level may further include four or more levels including sub-businesses. The granularity level can be defined as any number of levels. The granularity levels correspond to policy tags, measure tags, and administrative / business tags, respectively. Note that the hierarchical division in this embodiment is an example, and the granularity level can be defined as any number of levels, and may be defined as an even greater number of levels or an even lesser number of levels. Furthermore, the granularity level is not limited to the classification of policy, measure, administrative / business, and sub-business.

[0068] The related tag ID indicates a tag ID that identifies the relationship between the tag and other related tags in the tree structure. The relationship may be any relationship, such as a parent-child relationship, a sibling relationship, or a grandchild relationship, but it is preferable that the relationship be one that can identify at least the parent-child relationship of adjacent hierarchies. The tree structure is defined in the order of policy tags, action tags, and business / administrative tags, from top to bottom. For example, a policy tag may be defined by associating the tag ID of one policy tag as a related tag ID, and a business / administrative tag may be defined by associating the tag ID of one action tag as a related tag ID. Note that a policy tag may be defined by associating the tag IDs of one or more business / administrative tags as related tag IDs, and a policy tag may be defined by associating the tag IDs of one or more action tags as related tag IDs.

[0069] As shown in Figure 3, the policy system tag has a tree structure in which policy tag A (tag TA1) is the first tier, policy tag A (tag TA2) and policy tag B (tag TA3) which are children of policy tag A are the second tier, administrative business tag A (tag TA4) and administrative business tag B (tag TA5) which are children of policy tag A are the third tier, and minor business tag A (tag TA8) and minor business tag B (tag TA9) which are children of administrative business tag A are the fourth tier. Note that the number of tags forming the tree structure is an example and may be more or less than that shown in Figure 3.

[0070] Judgment axis tags are tags that classify judgment axes that provide judgment results or judgment criteria for a certain judgment subject related to a policy system. In this embodiment, judgment axis tags correspond to judgment subjects and include types such as assessment axis tags, financial resource tags, subject tags (financial settlement statistical journal entry tags, public accounting journal entry tags), and indicator tags. Judgment axis tags may be classified (grouped) according to the viewpoint of judgment. Note that subject tags may include item / sub-item tags that correspond to budget subject system items.

[0071] Judgment axis tags are classified and defined for the purpose of referencing the results of judgments made on a policy system when making administrative decisions on other policy systems. For example, when assessing a budget, financial department personnel would determine whether the requested amount was appropriate, such as whether the requested amount was the same as the previous year, whether it was on an increasing trend, or whether it was on a decreasing trend, based on their individual experience, skills, and unique judgment criteria. Judgment axis tags can be assigned to policy systems by defining the classification of these judgment criteria as tags on judgment axes such as "same as the previous year," "increasing trend," or "decreasing trend." Judgment axis tags summarize and visualize the process and results of the considerations that led to the assessment in question as judgment axes, and are referenced when making unified judgments that are not dependent on individual skills, etc.

[0072] In this embodiment, judgment axis tags are used for administrative judgments including assessment judgments, classification judgments, and proposal judgments. Judgment axis tags for assessment judgments include assessment axis tags related to assessment judgments of expenditure budgets and financial resource tags related to assessment judgments of revenue budgets (financial resources). Judgment axis tags for classification judgments include financial statement statistics tags related to classification judgments of financial statement statistical subjects and public accounting tags related to classification judgments of public accounting subjects. Judgment axis tags for proposal judgments include indicator tags related to proposal judgments of administrative goals. Judgment axis tags are configured with multiple judgment axes as tags for each judgment subject.

[0073] The decision axis tag can have a structure that corresponds to each decision subject. Fig. 4 is a schematic diagram of the structure of the decision axis tag.

[0074] As shown in FIG. 4A, judgment axis tags are classified by judgment perspective. There are one or more judgment perspectives, such as judgment perspectives C11 and C12, and individual judgment axes derived from judgment perspective C11 exist as one or more judgment axis tags TB1 and TB2. Furthermore, judgment axis tags TB3 and TB4 exist as judgment axes within judgment perspective C12. A judgment perspective includes a specific subject that indicates what subject the judgment was made on, and judgment axis tags may be classified by the specific subject. There is no limit to the number of judgment perspectives and judgment axis tags belonging to a judgment perspective.

[0075] The judgment axis tag may also include tags TC1 to TC3 related to revision rates. The revision rate C13 indicates the revision rate for the value of the judgment subject. If the judgment subject is a budget, the revision rate refers to the assessment rate for the requested amount; if the judgment subject is financial resources, the revision rate refers to the allocation rate of specific financial resources for the requested amount; if the judgment subject is an index, the revision rate for the KPI set as a target value.

[0076] The judgment axis tags TB1 to TB4 and the correction rate tags TC1 to TC3 can be linked independently. By combining these tags, it is possible to define information that correlates with the degree to which the value of the judgment subject should be corrected (correction rate) for the result of a certain judgment (judgment axis). The correction rate may also be integrated with the judgment axis tag.

[0077] As shown in FIG. 4B, the judgment axis tags TB1 to TB6 are classified into multiple groups. In classification judgment, for example, subjects, indicators, etc. are classified. Subjects are classified into hierarchical levels such as a major category C21, medium categories C31 and C32, and small categories C41 to C43. The classification type and number of levels can be set appropriately depending on the target and are not limited. The number of groups, such as major categories, medium categories, and small categories, is also not limited. These small categories can also be referred to as judgment perspectives. For example, the appropriate classification is considered within the judgment perspective of small categories, and the judgment axis tag, which is the final classification, is determined as a result of that judgment. Note that judgment axis tags are not limited to tags in the lowest-level classification; small categories and major categories can also be judgment axis tags. Judgment axis tags may also be configured without being grouped.

[0078] 3.5. Construction of Judgment Know-How DB 40 The judgment know-how DB 40 is constructed to provide judgment know-how related to a specific judgment subject of a policy system (administrative object). In this embodiment, the judgment subject includes at least one selected from budget, financial resources, items, and indicators. Judgment know-how refers to at least one of judgment perspectives, suggestions, results, numerical values, etc., which support the user's judgment on the judgment subject. Specifically, the judgment know-how includes at least a judgment perspective or classification and a judgment axis tag within the judgment perspective or classification. It is preferable that the judgment know-how further includes a revision rate.

[0079] An overview of the decision support according to this embodiment will be described with reference to FIG. 5. As shown in FIG. 5(a), the decision know-how DB 40 stores policy system tags, associated information, and decision know-how in association with each other. The decision know-how DB 40 may be configured to store policy system tags and associated information in association with each other, and to define the relationship between each piece of data by storing the associated information and the decision know-how in association with each other. In this embodiment, the associated information includes at least one selected from individual expense items, budget item system items, administrative goal item system items, organizational item system items, etc. Individual expense items include subsections as budget item system items for administrative projects or minor projects, and the subsections can be referenced as associated information.

[0080] This allows for budget assessment and judgment on the sub-items, which are the accompanying information, as shown in Figure 5(b). Specifically, it is possible to refer to the policy system tag associated with the sub-items of the expenditure budget included in the budget request, and the assessment axis tag and assessment rate, which are the assessment know-how.

[0081] Figure 5 (c) shows an example of the relationship between each data item in the administrative business information or minor business information and each data item in the judgment know-how DB 40. The administrative business information or minor business information is linked to individual expense items, and these individual expense items are linked to subsections. A policy system tag is assigned to the administrative business information or minor business information. Note that a policy system tag may also be assigned to individual expense items. An assessment perspective associated with the policy system tag and subsection is assigned to each individual expense item in the judgment know-how DB 40. This allows judgment know-how (assessment perspective) to be obtained from the policy system tag (policy system item) and accompanying information (individual expense items or subsections) when making budget decisions for administrative businesses or minor projects, thereby improving the efficiency of assessments and realizing budget assessments that are not dependent on individual skills.

[0082] As a modified example, the judgment know-how DB 40 further includes a special funds know-how DB 42. The special funds know-how DB 42 stores judgment know-how related to special funds, in association with accompanying information including individual expenditure items or budget item system items (subsections, etc.) of financial resources. The judgment know-how for special funds includes at least a financial resource tag indicating a special fund that is judged to be appropriateable based on the financial resource item. The judgment know-how for special funds may further include the allocation basis, appropriated expenses, and allocation rate of the special fund. The allocation basis and appropriated expenses are used as judgment viewpoints, and the financial resource tags may be classified according to the judgment viewpoints.

[0083] As shown in FIG. 5(d), the judgment know-how DB 40 stores policy system tags in association with data from the specific revenue DB 45. This enables assessment and judgment of revenue resources for the accompanying information, i.e., subsections. Specifically, the assessment and judgment of revenue resources can be performed by referring to the associated judgment know-how, i.e., revenue tag, judgment viewpoint, allocation rate, etc., using a judgment support request including the policy system tag and accompanying information (subsections, etc.). The judgment support request may also include values ​​of the judgment subject (requested amount, revenue request amount, target value, etc.).

[0084] As a variant, as shown in Figure 5(e), the judgment know-how DB 40 stores the policy system tag assigned to the task / project information or sub-project information, the associated sub-items, and the final budget amount after assessment of the sub-items. This allows for reference to the budget amount or average budget amount for each sub-item of other tasks / projects with the same policy system tag when considering the budget request or budget assessment amount for a certain task / project. Here, the other tasks / projects may be tasks / projects of other local governments, etc. (organizational system items).

[0085] The following is an example of a specific construction of the judgment know-how DB 40 related to administrative judgments. The judgment know-how DB 40 stores judgment know-how data. The judgment know-how data includes at least a judgment know-how ID, associated information, and judgment know-how. The judgment know-how data may further include a policy system tag. The judgment know-how DB 40 provides judgment know-how for at least one element, i.e., the type of item (associated item) of the associated information. The judgment know-how DB 40 can provide judgment know-how that is closer to the actual situation for two elements, i.e., the classification (policy system tag) of the policy system and the type of item (associated item) of the associated information. The judgment know-how of the judgment know-how data includes at least one of a judgment axis tag and a judgment perspective. Here, the judgment perspective may be a classification of the judgment axis tag (major classification, medium classification, minor classification, etc.). The judgment know-how may further include a correction rate. The judgment know-how DB 40 is constructed by linking a certain judgment perspective or judgment axis tag according to whether it is necessary for judging a certain associated item in a certain policy system tag. Furthermore, when a certain judgment viewpoint is necessary for judging a certain associated item, the judgment know-how DB 40 is constructed by further linking the correction rates thereof. The correction rates are linked by taking into consideration actual cases in local governments, etc.

[0086] FIG. 6( a) shows an example of the data structure of task and project information. In this embodiment, the task and project information includes one or more pieces of financial resource information. The task and project information also includes one or more pieces of sub-project information. The task and project information includes the following data items: task and project ID, task and project name, task and project purpose, start year, continuation year, end year, item, expenditure breakdown purpose (major category, medium category, minor category), requested amount, assessed amount, and preliminary amount, financial resource information, and sub-project information. The preliminary amount includes the following data items: financial resource classification, item and sub-item subsection, financial resource name, allocation reason, allocation basis, allocation rate, and revenue request amount, revenue assessment amount, and revenue preliminary amount. The revenue request amount, revenue assessment amount, and revenue preliminary amount indicate the requested amount for specific financial resources, which are revenue, and are listed separately from the requested amount, assessed amount, and preliminary amount, which include general financial resources. The allocation rate indicates the proportion of the specific financial resources identified by the financial resource information to the requested amount, etc. In other words, by applying the allocation rate to the requested amount, assessed amount, and forecast amount, the requested revenue amount, assessed revenue amount, and forecast revenue amount based on the specific financial resource are derived. The financial resource information may further include an upper limit on the amount that can be allocated (allocable amount). Figure 6 (b) shows an example of the data configuration of minor business information. The minor business information has one or more individual expense items. The individual expense items have one or more financial resource information. It is possible to adopt a configuration in which the administrative business information has one or more individual expense items.

[0087] The individual expense items have the following data items: individual expense item ID, individual expense item name, sub-item, expenditure breakdown purpose (major category, medium category, minor category), requested amount, assessed amount, provisional amount, and financial resource information. Financial resource information for minor projects has the same data items as the administrative project information.

[0088] In the judgment know-how DB 40, at least one or more items selected from the following can be used as associated items: sub-items of business operations, names of individual expenditure items, expenditure breakdown items, subsections of individual expenditure items, names of individual expenditure items, budget characteristics, and administrative goal system items. In addition, associated items are not limited to systematized data (budget item system items, local government financial status survey items, administrative goal system items), and unsystematized data (business operation names, sub-item names, individual expenditure item names, summaries, etc.) can be used by natural language processing.

[0089] The following describes the specific data configuration of the judgment know-how DB 40 according to the judgment subject. The judgment know-how DB 40 stores, as judgment know-how data, appraisal know-how data, special goods know-how data, classification know-how data, and proposal know-how data in an appraisal know-how DB 41, a special goods know-how DB 42, a classification know-how DB 43, and a proposal know-how DB 44, respectively.

[0090] 3.6. Building the Assessment Know-How DB 41 The following provides specific examples of assessment perspectives to consider when assessing budget requests for administrative projects. Assessment perspectives for budget assessment decisions include whether there is a reason for including the budget, whether there is consensus within the organization, who will be implementing the budget, whether there are similar projects, whether there are alternatives to discontinue, when the project should be implemented, how it should be implemented, whether financial resources can be secured, whether the requested amount is appropriate, the motivation of those on the ground, and the final decision. In this embodiment, there are 10 categories for "assessment perspectives," and 104 categories for "assessment axis tags." These "assessment axis tags" belong to one of the 10 categories of "assessment perspectives." The Finance Division assesses the requested amount according to the 10 assessment perspectives and assigns the "assessment axis tags" used in the assessment judgment to the policy system or its associated information. Since budget assessments involve assessment decisions for each individual expense item included in the requested amount, assessment axis tags are assigned to the individual expense items included in the requested amount or their corresponding sub-items. The assessment axis tag may be assigned to the policy system information according to the type of “assessment viewpoint” or “assessment axis tag.” The types and quantities of the assessment viewpoint and assessment axis tag are not limited to these.

[0091] The assessment axis tag includes a tag indicating a specific subject. "Specific subjects" are a classification of which subjects were assessed. "Specific subjects" specifically include categories such as "souvenirs," "subsidies," "printed materials," "repairs," "supplies," "consumables," and "labor costs." Note that specific subjects may be classified as one aspect of assessment.

[0092] The assessment axis tag includes a tag indicating an "assessment rate." The assessment rate is applied to the requested amount and used to calculate the assessed amount. The assessment is typically a reduction assessment, which reduces the requested amount, but is not limited to this and may also include an increase assessment, which increases the requested amount. For example, the assessment rate is set in the range of 0 to 1 for a reduction assessment. If the assessment rate is 0, the reduction amount is 0 (the requested amount multiplied by 0), and the assessed amount is the same as the requested amount. If the assessment rate is 0.2, the reduction amount is 20% of the requested amount (the requested amount multiplied by 0.2), and the assessed amount is 80% of the requested amount. If the assessment rate is 1, the reduction amount is equal to the requested amount (the requested amount multiplied by 1), and the assessed amount is 0. Note that in this embodiment, the assessment rate indicates a reduction rate, but is not limited to this. For example, if the assessment rate is 0.2, the assessed amount is 20% of the requested amount, and if the assessment rate is 1.0, the assessed amount can be the same as the requested amount. In this case, an assessment rate greater than 1.0 can result in an increase assessment.

[0093] The assessment axis tag is assigned by combining a tag related to the assessment viewpoint and a tag related to the assessment rate. For example, even if different businesses are assigned tags related to a common assessment viewpoint, they can each be assigned tags related to a different assessment rate. This allows each business to obtain a different assessment rate for a certain assessment viewpoint.

[0094] In a modified version of the assessment axis tag, a tag related to the assessment viewpoint and a tag related to the assessment rate are assigned together. For example, if a tag related to a common assessment viewpoint is assigned to each of different businesses, the same assessment rate can be obtained. This allows the assessment rate for a tag related to a certain assessment viewpoint to be obtained fixedly.

[0095] The following illustrates a specific example of the construction of the appraisal know-how DB 41. FIG. 7A shows an example of appraisal know-how data stored in the appraisal know-how DB 41. The subject of appraisal judgment is the determination of whether the budget request amount for the budget item system item (sub-item / sub-item) of the policy system is appropriate. In other words, a judgment can be made based on judgment know-how (assessment perspective, assessment axis tag) related to a certain appraisal judgment, at least for one element, namely, the type of item (sub-item / sub-item) of the budget item system. For a judgment closer to reality, a judgment is made based on judgment know-how (assessment perspective, assessment axis tag) for two elements, namely, the classification of the policy system (policy system tag) and the type of item (sub-item / sub-item) of the budget item system. In budget appraisal judgment, the administrative object in question is an administrative project or a sub-project, so the budget item system item is a sub-item. In the appraisal know-how data, individual expense items corresponding to the sub-item may be used as ancillary items. The appraisal know-how DB 41 stores at least one or more appraisal perspectives or one or more decision axis tags linked to each subsection. Preferably, the appraisal know-how DB 41 stores one or more appraisal perspectives or one or more decision axis tags linked to each combination of a policy system tag and a subsection. The appraisal know-how data may further include an appraisal rate. The appraisal know-how DB 41 is constructed by performing an association process based on whether a certain appraisal perspective or appraisal axis tag is necessary for a budget request or budget appraisal for a certain subsection in a certain policy system tag. Furthermore, if a certain appraisal perspective is necessary for a budget request or budget appraisal, the appraisal know-how DB 41 further associates and stores an appraisal axis tag, which is a more specific judgment result, and its appraisal rate (the ratio of the appraised amount to the requested amount). The appraisal rate is associated with actual cases in local governments, etc.

[0096] 3.7. Construction of the Special Funds Know-How DB 42 The special funds know-how DB 42 is constructed to provide know-how for making decisions regarding specific funds used as budget sources for policy systems (administrative objects). The special funds know-how DB 42 is constructed using financial resource information stored in the specific financial resource DB 45. The specific financial resource DB 45 stores financial resource information as shown in FIG. 7(b). The financial resource information includes financial resource identification information (financial resource ID), identification information of related individual expenditure items (individual expenditure item ID), financial resource name, revenue amount for each topic, financial resource allocation rate, financial resource classification, item item subsection (budget item: budget item system item), responsible department (organizational system item), allocation basis, and allocation reason. The budget item system items (item item subsections) of financial resource information are, for example, national treasury disbursements > national treasury subsidies > general administrative expenses national treasury subsidies > regional revitalization grants, and the use thereof is specified. The budget item system items for revenues (financial resources) are different from the budget item system items for expenditures. Financial resource information may also include the appropriable amount. The basis for appropriation includes the system guidelines for grants, etc., and may also include the relevant clauses, regulations, requirements, etc. in the guidelines. Appropriable expenses indicate specific types of expenses that can be appropriated, such as road development expenses, public facility expenses, and public servant salaries. Financial resource tags are tags that correspond to financial resource names such as "regional revitalization promotion grants." Financial resource tags are defined as tags that correspond to financial resource names that correspond to specific financial resources such as national treasury disbursements, prefectural disbursements, local bonds, contributions, charges, usage fees, fees, and donations.

[0097] The special funds know-how DB 42 stores special funds know-how data as shown in FIG. 7( c). The special funds know-how DB 42 stores special funds know-how data that links accompanying information (individual expenditure items, subsections) and judgment know-how (financial source tags, etc.) of financial resource information to policy system information (administrative project tags, minor project tags). In this embodiment, the accompanying information is the individual expenditure items or subsections included in the financial resource information. Furthermore, the judgment know-how for specific financial resources (special funds know-how) includes one or more pieces of arbitrary data that can be used to assess and judge the financial resources included in the financial resource information. In this embodiment, the judgment know-how for specific financial resources includes a financial resource tag (judgment axis tag) that indicates the name of the specific financial resource included in the financial resource information. Furthermore, the judgment know-how may include an allocation perspective, such as the basis for appropriation of the financial resource information or appropriable expenses. The financial resource tag may be configured to belong to a classification of allocation perspectives. Furthermore, the judgment know-how for specific financial resources may further include an allocation rate to be applied to the requested amount. In addition, if an appropriable amount is set, the special revenue know-how may include the appropriable amount in addition to or instead of the allocation rate. The special revenue know-how DB 42 is not limited to the data structure shown in FIG. 7(c), and may be configured to associate a funding source ID with policy system information and store it as special revenue know-how data. The subject of judgment in the assessment and judgment of special revenue is whether the revenue (funding source) included in the budget request related to the budget item system item (subitem item subsection) of the policy system is appropriate. In other words, it is possible to make a judgment based on judgment know-how (appropriation perspective, funding source tag) related to a certain special revenue, based on at least one element, namely, the type of item in the budget item system. For a judgment that is closer to reality, it is possible to make a judgment based on judgment know-how (appropriation perspective, funding source tag) based on two elements, namely, the classification of the policy system (policy system tag) and the type of item in the budget item system (subitem item subsection). In assessing financial resources, the administrative objects to be assessed are administrative projects or minor projects, and therefore the budget item system items are sub-items. In the specific financial resources data, individual expenditure items corresponding to the sub-items may be adopted as accompanying items. The special financial know-how DB 42 stores at least individual expenditure items or sub-items, linked with one or more financial resource tags or one or more allocation perspectives.Preferably, the special funds know-how DB 42 stores one or more allocation perspectives or one or more financial resource tags associated with a combination of a policy system tag and a sub-item. The special funds know-how data may further include an allocation rate.

[0098] 3.8. Construction of the Classification Know-How DB 43 The classification know-how DB 43 is constructed to provide classification know-how for determining items such as subjects of the administrative system (administrative object). In this embodiment, the classification determination determines how to classify (journalize) budget subject system items into settlement statistics tags, which are subjects related to settlement statistics (local government financial status surveys), and public accounting tags, which are subjects related to local government accounting.

[0099] Financial statement statistics tags have decision axis tags corresponding to items with budget characteristics and expenditure breakdown purposes. Financial statement statistics are compiled based on uniform rules regarding the financial status of local governments each fiscal year and are used for comparison and analysis of the finances of each local government. Specifically, financial statement statistics tags include tags such as labor costs (major category) and vocational training costs (medium category) for expenditure breakdown purposes, as well as tags such as property costs (major category) and other (medium category) for budget characteristics. Public accounting tags have decision axis tags corresponding to items such as general account balance sheets, general account administrative cost and net asset change plans, and general account cash flow statements, which are financial documents used in local government accounting. Local government accounting refers to a government accounting system established as uniform standards for local governments and operated with the aim of increasing financial transparency and fulfilling accountability to residents. Public accounting items are classified according to a hierarchy, similar to items in the budget item system and local government financial status survey. Specifically, the public accounting tags include tags for assets, which are classified in the hierarchy from top to bottom, in the order of fixed assets, tangible fixed assets, business assets, and land.

[0100] Specific examples of the construction of the classification know-how DB 43 related to classification judgments are shown below. Figures 7(d) and (e) show examples of the data structure of classification know-how data stored in the classification know-how DB 43. Figure 7(d) shows classification know-how data including financial statement statistics tags. Figure 7(e) shows classification know-how data including public accounting tags. The classification know-how data may have a data structure that includes financial statement statistics tags and public accounting tags as a single entity. In the classification judgment, it is determined whether the budget item system items (sub-item items, sub-items), local government financial status survey items (budget nature, expenditure breakdown purpose), or public accounting item items of the policy system that is the subject of judgment are appropriate. In other words, it is possible to classify and judge at least one of the appropriate financial statement statistics tags (expenditure breakdown purpose, budget nature) and public accounting tags (public accounting items) for at least one element, namely, the type of item (sub-item items, sub-items) of the budget item system. For a more realistic assessment, at least one of the settlement statistics tag and the public accounting tag can be classified based on two factors: the classification of the policy system (policy system tag) and the type of budget item. In the classification assessment, the target administrative object is an administrative project or a minor project, so the budget item is a sub-item or a sub-section. For administrative projects, as shown in Figure 6(a), the classification is determined for the expenditure breakdown purpose corresponding to the sub-item. For minor projects, as shown in Figure 6(b), the classification is determined for the budgetary nature of the sub-item. Similarly, public accounting tags are classified according to the granularity of the budget item. Classification know-how data can be configured by linking sub-item and sub-section tags to combinations of policy system tags and individual expenditure items. Here, non-systematic data such as the name of the individual expenditure item is used for the individual expenditure items, and the sub-item tag for the corresponding sub-section is linked to it.

[0101] <3.9. Construction of Proposal Know-how DB 44> The proposal know-how DB 44 is constructed in order to provide proposal know-how that uses indicators of the policy system (administrative object) as the subject of judgment.

[0102] In this embodiment, the indicators are administrative objectives (KPIs). The proposal and judgment process includes, for example, proposing appropriate indicators to be set for new or existing projects. It also includes proposing appropriate target values ​​to be set for the set indicators. Ideally, the actual value of a KPI increases or decreases in conjunction with the budget amount. For example, in an employment promotion project, increasing the labor cost budget is expected to increase the number of employees, which is the KPI. Based on this, it can be understood that if a budget item (item subsection) related to a certain policy system can be identified, it is possible to propose appropriate administrative objectives (indicators) linked to the budget item. Furthermore, by identifying the budget item and the budget amount associated with it, it is possible to propose revisions to indicators and their target values.

[0103] The following illustrates a specific example of the proposal know-how DB 44 for proposal judgments. FIG. 7( f ) shows an example of proposal know-how data stored in the proposal know-how DB 44. In proposal judgments, judgments are made to propose appropriate indicators or their index values ​​(target values) for budget item items (subitem subsections) of the policy system, which is the subject of judgment. That is, a proposal can be made based on judgment know-how (indicator tags) for a certain proposal judgment, with respect to at least one element: the type of item (subitem subsection) of the budget item system. For judgments closer to reality, a proposal is made based on judgment know-how (indicator tags) for two elements: the classification (policy system tag) of the policy system and the type of item (subitem subsection) of the budget item system. In the indicator proposal judgment, the target administrative object is an administrative project or a subproject, so the budget item system item is a subsection. In the proposal know-how data, individual expenditure items corresponding to the subsections may be used as accompanying items. The proposed know-how DB 44 associates one or more index tags with at least each section and subsection, and stores the associated data. Preferably, the proposed know-how DB 44 associates one or more index tags with each combination of a policy system tag and a section and subsection, and stores the associated data. The proposed know-how data may further include a revision rate. In this embodiment, the index tags are configured as tags corresponding to administrative goal system items in a hierarchical structure. The proposed know-how data may be configured to include, for an index tag in a lower level, an index tag in a higher level as judgment know-how.

[0104] A modified example of the proposal know-how DB 44 will be described. The proposal know-how DB 44 stores proposal know-how data including a policy system tag, associated information including a budget item system item or an index tag, and proposal know-how including a judgment axis tag (proposal axis tag) related to a proposed revision of an index value. Here, the associated information may further include a budget item system item. Like the assessment know-how data, the proposal know-how data has one or more proposal perspectives and multiple proposal axis tags belonging to the proposal perspectives. The proposal know-how data may also include a revision rate of an index value. The proposal perspective classifies perspectives to be considered when proposing a revision of an index value. The proposal axis tag is used to consider an index value according to the proposal perspective, and the proposal axis tag adopted in the judgment is assigned to the policy system or its associated information. As a specific example, the proposal know-how data associates proposal know-how including a proposal axis tag, a proposal perspective, and a revision rate with a combination of an administrative business tag or a minor business tag and an index tag. The proposed know-how data may be configured to associate proposed know-how with a combination of a business tag or a sub-business tag, an index tag, and a subsection. This allows for determining whether a target value is appropriate when an index is set for a business, and for proposing a revision of the target value if it is not appropriate. Furthermore, budget-related information can be taken into consideration when proposing the target value.

[0105] 3.10. Administrative Data Management Unit 21 The administrative data management unit 21 accepts input related to various administrative data from the user terminal 3 and registers the administrative data in the database 4. The following describes the registration of administrative business information, which is administrative data related to administrative businesses.

[0106] <3.11. Tag Processing Unit 23> The tag processing unit 23 assigns a policy system tag to the policy system information. By assigning a policy system tag to the policy system information, the policy system tag (administrative project tag / sub-project tag) is also linked to the associated items (budget subject system items (subsections, etc.), individual expense items, administrative target system items, etc.) of the associated information (budget information, financial resource information, administrative target information) included in the policy system information (administrative project, sub-project, etc.). Here, by linking the administrative project tag or sub-project tag to the associated items of the policy system information (target policy system information) that is the target for which decision support is required, the generation of decision support information using the decision know-how DB 40 is realized.

[0107] The tag processing unit 23 accepts the designation of a policy system and the designation of a policy system tag to be linked to the policy system, and associates the policy system tag with the designated policy system information and stores it in the database 4.

[0108] The tag processing unit 23 can input summaries such as the project name / subproject name, project summary / subproject summary, project plan, affiliation name, and sections and subsections included in the administrative project / subproject into the classification model, and output a policy system tag as the classification result. The tag processing unit 23 can be configured to associate the policy system tag output as the classification result with the administrative project / subproject and store it in the database 4. The classification model is a model trained by machine learning using a dataset. In this embodiment, the model can employ a neural network, a regression model, a decision tree, a k-nearest neighbor model, etc.

[0109] Datasets used for machine learning of classification models include the following aspects. In one aspect, the dataset includes text data related to an outline of a policy, program, or business project, and a classification result including at least basic tags such as a policy tag, program tag, program tag, program tag, or minor program tag. In one aspect, the dataset includes text data related to an outline of a policy, program, or business project, and a classification result including one or more keywords corresponding to the basic tags. In this case, the basic tags and corresponding keywords are stored in a storage unit DB as a correspondence table, and the system can be configured to further output basic tags corresponding to the keywords output as the classification result.

[0110] In this embodiment, the classification model includes a plurality of classifiers, each of which outputs a classification result for an input, and is provided at least one classifier for each layer of tag information, and passes the classification result output to a classifier provided at the next layer.

[0111] FIG. 8 shows an example of the configuration of the classification model M in this embodiment. According to FIG. 8, the classification model M includes a first classifier MA1 that receives input of text data related to an outline of a policy, program, or business project and outputs a classification result for a policy tag; second classifiers MB1 and MB2 that receive input of the classification result of the first classifier MA and output a classification result for a program tag; and third classifiers MC1 and MC2 that receive input of the classification result of the second classifier MB and output a classification result for a business tag. The classification model M may further include a fourth classifier that receives input of the classification result of the third classifier MC and outputs a classification result for a minor business tag, and the classifiers can be configured according to the number of hierarchies.

[0112] In this embodiment, the classifiers may be machine-trained using the above-mentioned datasets, respectively.

[0113] Each classifier outputs multiple tag information as a classification result and their likelihoods. The likelihoods are indicators or estimates that indicate the degree of probability that the tag information output as the classification result is the tag information.

[0114] In the classifier according to this embodiment, a threshold is set for the likelihood distribution. The likelihood distribution is the distribution of the likelihood of each of a plurality of pieces of tag information, and is classified into, for example, the following patterns: Pattern 1: The likelihood of a specific tag is higher than the likelihood of other tags. Pattern 2: The likelihood of each tag is relatively equal.

[0115] Pattern 1 is identified by setting a threshold value for the difference between the likelihood of a specific tag and the likelihood of other tags. Note that there may be multiple specific tags. Pattern 2 is identified by setting a threshold value for the difference in likelihood of multiple tags. Note that in Pattern 2, a predetermined number of tags may be set, and a threshold value may be set for the difference in likelihood of tags for that number of tags.

[0116] The classifier identifies at least one of the above patterns based on a threshold set in the likelihood distribution and determines whether to input the classification result to a lower classifier. For example, if the pattern is 1, the classifier inputs the classification result to the lower classifier, and if the pattern is 2, the classifier does not input the classification result to the lower classifier. In the case of pattern 2, the classification model M outputs a classification result including tag information corresponding to the classifier to which the classification result was last input. This makes it possible to output, as the classification result, tags that are highly likely to be tag information in a higher hierarchy, such as policy tags or action tags.

[0117] Referring to Figure 8, the flow of outputting classification results for business tags will be described. The first classifier MA1 accepts input of text data of a business summary of business information, and outputs a classification result including a policy tag B1 and a likelihood of 0.95 to classifier MB1, and a classification result including a policy tag B2 and a likelihood of 0.05 to classifier MB2. Classifier MB1 accepts input of classification results, and outputs a classification result including a policy tag C1 and a likelihood of 0.75 to classifier MC1, and a classification result including a policy tag C2 and a likelihood of 0.25 to classifier MC2. Classifier MC1 accepts input of classification results, and outputs a classification result including a business tag A and a likelihood of 0.88, and a classification result including a business tag B and a likelihood of 0.12. Classifier MC2 accepts input of classification results, and outputs a classification result including a business tag C and a likelihood of 0.58, and a classification result including a business tag D and a likelihood of 0.42. Here, classifiers MC1 and MC2 are set with a likelihood distribution threshold of, for example, 0.5. Classifier MC1 identifies the likelihood distribution as pattern 1 and outputs office / business tag A and office / business tag B as the classification result. Classifier MC2 identifies the likelihood distribution as pattern 2 and outputs policy tag C2 as the classification result. Classification model M outputs office / business tag A, office / business tag B, policy tag C2, and their respective likelihoods as the classification result. The likelihoods are derived by calculating the likelihoods output by each of the first to third classifiers that have passed through. The likelihood calculation is, for example, multiplication, and the likelihood of office / business tag A is 0.95 * 0.75 * 0.88 = 0.627, the likelihood of office / business tag B is 0.95 * 0.75 * 0.12 ≒ 0.086, and the likelihood of policy tag C2 is 0.95 * 0.25 ≒ 0.238. These classification results are displayed as tag names and scores on the display unit 905 of the user terminal 3 as a tag screen (not shown).

[0118] The tag screen displays tag names in descending order of likelihood based on the likelihood, which is the classification result of the classification model M. In one embodiment, the displayed tag names may include the administrative / business tag A, which is finally output via classifiers MA1, MB1, and MC1, and may further include the policy tag B1 corresponding to classifier MA1 and the action tag C1 corresponding to classifier MB1. In one embodiment, the displayed tag names may include the administrative / business tag A, which is finally output via classifiers MA1, MB1, and MC1, and may only include the final output administrative / business tag A. Even if the likelihood of administrative / business tag A is smaller than the likelihood of policy tag B1 or action tag C1, if the likelihood distribution is pattern 1, it is highly likely to be the tag name output by a lower-level classifier. This makes it possible to more efficiently select and determine tag names.

[0119] The tag processing unit 23 assigns a judgment axis tag to at least the accompanying information in association with the judgment axis tag. The tag processing unit 23 assigns a judgment axis tag to a combination of policy system information and accompanying information in association with the judgment axis tag. The judgment know-how DB 40 stores the judgment know-how data to which the tag processing unit judgment axis tag has been assigned.

[0120] <3.12. Generator 24> The generator 24 generates decision support information in response to a decision support request related to target policy system information requiring decision support. The decision support request includes at least a specification of the target associated information (budget item system items, individual expense items, etc.). It is preferable that the decision support request further includes a specification of the administrative project or subproject (administrative project tag / subproject tag) to be targeted as the target policy system information. The decision support request may also include a specification of a decision subject. The specification of the decision subject is automatically set, for example, on a screen for setting the budget, financial resources, items, indicators, etc.

[0121] The generation unit 24 references the judgment know-how DB 40 in response to a judgment support request. Based on at least the accompanying information included in the judgment support request, the generation unit 24 references the accompanying information (budget subject system items: subsections) stored in the judgment know-how DB 40 and acquires judgment know-how data related to the judgment know-how ID associated with the accompanying information. The generation unit 24 may also be configured to reference a combination of accompanying information and policy system tags stored in the judgment know-how DB 40 based on the accompanying information and policy system tags (administrative business tags / sub-business tags) included in the judgment support request and acquire information related to the judgment know-how ID associated with the combination. The acquired information includes at least one of the judgment perspective, judgment axis tags (axis / specific subject), and revision rate. Note that, if there are multiple judgment know-how IDs associated with the accompanying information or the combination of the accompanying information and policy system tags, the generation unit 24 acquires information related to the multiple judgment know-how IDs. The generation unit 24 can acquire judgment know-how data by referring to at least one database selected from the appraisal know-how DB 41, the special property know-how DB 42, the classification know-how DB 43, and the proposal know-how DB 44 according to the specified judgment subject.

[0122] The generating unit 24 generates decision support information based on the acquired information. The decision support information includes at least a decision viewpoint, a decision axis tag, and a correction rate corresponding to the accompanying information included in the decision support request.

[0123] The generating unit 24 generates the judgment support information as a list of multiple judgment know-how. The generating unit 24 may also generate the judgment support information based on the aggregation results of multiple judgment know-how. For example, the aggregation results are generated by aggregating common judgment perspectives or judgment axis tags, and those with the largest aggregation counts are preferentially generated as judgment support information. The judgment support information may include the aggregated number of common judgment perspectives or judgment axis tags or their ratio to the total number. The aggregation results may also include an average correction rate related to the common judgment perspectives or judgment axis tags. The generating unit 24 can generate judgment support information that can distinguish between those with a common judgment perspective but different judgment axis tags.

[0124] The output unit 27 outputs this decision support information to the user terminal 3. This allows the user to obtain a judgment perspective that corresponds to the classification of the business or minor business related to the business or minor business that requires decision support, as well as the ancillary items that are the subject of the judgment (such as details related to individual expense items), and allows the user to make judgments such as assessments in accordance with this judgment perspective.

[0125] The obtained adjustment rate is applied to the value of the judgment subject (request amount, revenue request amount, target value, etc.) and used to calculate the adjustment value (assessed amount, revenue assessment amount, adjusted target value, etc.). The adjustment value can be calculated using an average adjustment rate (average assessment rate, etc.) or a total adjustment rate (total assessment rate, etc.). The average adjustment rate or composite adjustment rate is applied to the value of the judgment subject and used in the process of calculating the adjustment value. The average adjustment rate is obtained by obtaining multiple adjustment rates and taking their average. Here, the average adjustment rate can be the average of multiple adjustment rates for a common judgment perspective or judgment axis tag. The total adjustment rate is obtained by obtaining multiple adjustment rates and taking their sum. Here, the total adjustment rate can be the sum of multiple adjustment rates for different judgment perspectives. It is more preferable to obtain the total adjustment rate by calculating the average adjustment rate for a common judgment perspective and then summing the multiple average adjustment rates for different judgment perspectives.

[0126] The average correction rate or the total correction rate can be selected arbitrarily. The average correction rate is advantageous in calculating a correction value comprehensively. The total correction rate is advantageous in calculating a correction value using a point deduction system. In addition, the individual judgment viewpoints and their correction rates used in calculating the average correction rate or the total correction rate may be configured to be arbitrarily selectable.

[0127] Figure 9 shows an example of the display of the assessment screen W10 on the user terminal 3 during assessment judgment. The assessment screen W10 is displayed when target policy system information is specified and decision support for assessment judgment is requested. Figure 9 shows an example in which an administrative business related to "child medical expenses assistance" is specified and the assessed amount for the requested amount for that administrative business is determined. The assessment screen W10 includes an administrative business information area W11, an assessment information area W12 that displays decision support information related to assessment know-how, and a special fund information area W13 that displays decision support information related to special fund know-how.

[0128] The administrative business information area W11 displays the organizational information of the administrative business (local government name: City A), fiscal year, administrative business name (child medical expenses assistance), department information (bureau name, department name: Department A, section name: Section A), policy system tag (tag ID: T001, tag name: child support allowance payment), requested amount, assessed amount, assessment difference, AI assessed amount, special fund amount, AI special fund amount, one or more assessment perspectives or assessment axis tags (perspective / axis 1: actual results) applied from the assessment information area W12, and one or more funding tags (special fund name 1: national treasury contribution for child support allowance payments) applied from the special fund information area W13.

[0129] The assessment information area W12 displays judgment support information related to assessment know-how. In FIG. 9, the assessment information area W12 displays a list of assessment axis tags and their assessment rates. The assessment information area W12 may also display a list of assessment perspectives. The assessment rate may also be the average assessment rate. The assessment information area W12 accepts the specification of one or more assessment perspectives or assessment axis tags and can apply them to the business operations in the business operations information area W11. The applied assessment perspectives or assessment axis tags are reflected in the assessment perspectives or assessment axis tags (perspective / axis 1, perspective / axis 2, ...) in the business operations information area W11. The assessment information area W12 shows, for example, that the average assessment rate for the assessment axis tag "declining trend" is 0.1 and the average assessment rate for the assessment axis tag "execution rate" is 0.2.

[0130] The special funds information area W13 displays decision support information related to special funds know-how. In FIG. 9, the special funds information area W13 displays a list of funding tags and their allocation rates or appropriable amounts. The special funds information area W13 may further display a list of allocation grounds and appropriable expenses. The special funds information area W13 accepts the designation of one or more funding tags and can apply them to the tasks and projects in the task and project information area W11. The applied funding tags are reflected in the funding tags (Special Fund Name 1, Special Fund Name 2, ...) in the task and project information area W11. The special funds information area W13 shows, for example, that the appropriable amount for the "XX Promotion Project" is 10,000,000 yen and the average allocation rate for the "National Treasury Contribution for Child Rearing Allowance Benefits" is 0.3.

[0131] The process related to the display of the appraisal screen W10 will be described. By accepting the designation of target policy system information, the generation unit 24 acquires the policy system tag (administrative / business tag or sub-business tag) and budget item system item (subsection or individual expense item) associated with the target policy system information. For the acquired combination of policy system tag and budget item system item, the generation unit 24 references the judgment know-how DB 40 and acquires the appraisal know-how and special fund know-how associated with the combination. The generation unit 24 generates judgment support information related to the acquired appraisal know-how and judgment support information related to the special fund know-how. The output unit 27 outputs the judgment support information to the user terminal 3, thereby displaying the appraisal information area W12 and the special fund information area W13 of the appraisal screen W10, respectively. The administrative / business information area W11 accepts input of an appraisal amount based on the appraisal perspective, etc., applied from the appraisal information area W12. The appraisal difference indicates the difference associated with the appraisal, obtained by subtracting the appraisal amount from the requested amount. The AI ​​assessment amount indicates the assessment amount obtained by applying the assessment rate associated with the applied assessment perspective or assessment axis tag to the requested amount. In Figure 9, the assessment rate of 0.2 associated with the "Actual Results" assessment axis tag is applied to the requested amount, resulting in an AI assessment amount of 400,000 yen (request amount 500,000 yen x (1.0 - assessment rate 0.2) = 400,000 yen). When an assessment perspective or assessment axis tag is added or deleted in the administrative business information area W11, the AI ​​assessment amount fluctuates according to the assessment rate. When multiple assessment rates are applied in the administrative business information area W11, the average assessment rate or total assessment rate is applied to the requested amount to calculate the AI ​​assessment amount. The final assessment amount and assessment axis tag are registered with reference to the AI ​​assessment amount and assessment know-how decision support information. The administrative business information area W11 accepts input of the special fund amount (requested revenue amount) based on the applied funding source tag from the special fund information area W13. The AI ​​special fund amount indicates the special fund amount (allocated amount) obtained by applying the allocation rate for the applied funding tag to the requested amount. The AI ​​special fund amount also indicates the special fund amount obtained by allocating the allocable amount for the applied funding tag. In Figure 9, the allocation rate of 0.3 for the funding tag "National Treasury Contribution for Child Rearing Allowance Benefits" is applied to the requested amount, resulting in an AI special fund amount of 120,000 yen (Requested amount 500,000 yen x Allocation rate 0.3 = 120,000 yen).When a funding tag is added or deleted in the administrative business information area W11, the AI ​​special fund amount changes depending on the allocation rate or allocable amount. When multiple allocation rates are applied to the administrative business information area W11, the average allocation rate obtained by averaging them or the total allocation rate obtained by summing them is applied to the requested amount to calculate the AI ​​special fund amount. When an allocable amount is linked to a funding tag, the total allocable amount is calculated as the AI ​​special fund amount. Note that allocation rate and allocable amount can coexist. The final special fund amount and funding tag will be registered by referring to the decision support information for the AI ​​special fund amount and special fund know-how.

[0132] In this embodiment, the output unit 27 can display a list of judgment perspectives or judgment axis tags on a screen. The output unit 27 can display a list of policy system tags linked to a specified judgment perspective or judgment axis tag on a screen. The screen may particularly display a list of administrative / business tags or minor business tags. Furthermore, the output unit 27 can display administrative / business tags or minor business tags linked to judgment perspectives or judgment axis tags of other organizations, etc. The output unit 27 can display a list of policy systems (policies, measures, administrative / business projects, minor projects, etc.) linked to a specified policy system tag on a screen. The screen may also be capable of displaying policy systems of other organizations, etc. The output unit 27 can display the assessment screen of FIG. 9 by receiving a policy system designation on the screen. In this case, the authority to display or edit the assessment screen related to the policy system of other organizations may be restricted.

[0133] While the above describes an embodiment of the assessment judgment, similar embodiments can also be adopted for classification judgment and proposal judgment. The generation unit 24 acquires a judgment support request including a combination of policy system tags and budget item system items related to the target policy system, and generates judgment support information based on the classification know-how and proposal know-how associated with the combination by referencing the judgment know-how DB 40. The output unit 27 outputs the judgment support information to the user terminal 3, thereby displaying financial statement statistics tags, public accounting tags, index tags, etc. that can be applied to the target policy system. In classification judgment, financial statement statistics tags or public accounting tags applicable to administrative projects or minor projects are specified via a classification screen (not shown) and linked to individual expense items or budget item system items for registration. In proposal judgment, an administrative project information area including indicators for administrative projects or minor projects and their target values ​​is displayed on the screen, and by applying index tags, the correction rate associated with the index tag is reflected in the target value, and the AI ​​target value is calculated. The final target value and index tag are registered via a proposal screen (not shown) while referring to the judgment support information for the AI ​​target value and proposal know-how. The classification screen and proposal screen may be configured as independent screens, or may be provided as a classification information area and a proposal information area on the appraisal screen W10.

[0134] 3.13. Updating the Judgment Know-How DB 40 When the administrative data management unit 21 receives assessment amounts, special fund amounts (revenue assessment amounts), target values, etc. related to the target policy system, it registers them linked to the target policy system information. At this time, the tag processing unit 23 may link each judgment axis tag to associated information (individual expense items, budget item system items, and financial resource information). The tag processing unit 23 can link a judgment axis tag included in the judgment support information to the corresponding associated information by specifying the judgment axis tag included in the judgment support information, or automatically. Note that the tag processing unit 23 can also link a judgment axis tag to the corresponding associated information by specifying a judgment axis tag not included in the judgment support information. The judgment know-how DB 40 is configured to be updatable based on judgment know-how associated with judgments related to the target policy system.

[0135] The judgment know-how DB 40 is updated as each administrative organization makes a new judgment. The judgment know-how DB 40 receives instructions from each administrative organization to register judgment know-how and stores the judgment know-how data. The judgment know-how DB 40 may store the judgment know-how data before and after the update, or may store the judgment know-how data before and after the update separately.

[0136] Below, we will explain an example of the appraisal know-how DB 41 that is updated in accordance with appraisal judgments. The administrative data management unit 21 accepts registration instructions including the results of appraisal judgments (judgment know-how data) related to the target policy system (administrative projects, minor projects). The administrative data management unit 21 may also accept registration instructions including the results of appraisal judgments related to individual expense items or sub-items of the target policy system. The results of appraisal judgments include the appraisal amount and the appraisal perspective or judgment axis tag. The results of appraisal judgments are entered, for example, via the appraisal screen W10 of Figure 9, but this is not limited to this.

[0137] The judgment know-how DB 40 stores, as judgment know-how data, the combination of policy system tags (business tags, minor business tags) included in the registration instruction, sub-items or individual expense items linked to the policy system, the assessed amount resulting from the assessment judgment, and the assessment know-how (assessment perspective, assessment axis tags, assessment rate). Here, the assessed amount is said to be the final budget amount for the target policy system. The assessment rate may be calculated from the assessed amount relative to the requested amount. Furthermore, the organizational system item, which is the local government or the like that manages the policy system included in the registration instruction, may be further included in the judgment know-how data.

[0138] Figure 10 shows an example of the data structure of updated judgment know-how data. Figures 10(a) to 10(e) show only the updated data for assessment know-how data, special fund know-how data, classification know-how data (financial settlement statistics), classification know-how data (public accounting), and proposal know-how data. These judgment know-how data are linked to a combination of policy system tags and associated information (subsections or individual expenditure items). As shown in Figure 10, the updated judgment know-how data includes an organizational ID (organizational system item) that manages the target policy system, and includes assessment amounts, revenue assessment amounts, target values, etc. for each administrative organization. Here, administrative organizations include local governments, government agencies, etc., and may also include departments within local governments, etc. Note that the organizational ID may be linked to either the target policy system information, individual expenditure items, or financial resource information.

[0139] This allows the construction of a judgment know-how DB 40 that reflects judgment axis tags, appraisal amounts, etc. for each organizational system item. The generation unit 24 can select one or more judgment know-how DBs 40 for each organizational system item and generate judgment support information.

[0140] 3.14. Processing by the Generator 24 After Update The following describes processing by the generator 24 using the updated judgment know-how DB 40. Note that a description of processing similar to that performed by the generator 24 using the judgment know-how DB 40 before the update will be omitted.

[0141] The generating unit 24 generates decision support information in response to a decision support request related to target policy system information requiring decision support. Here, the decision support request includes at least a designation of the target administrative business or sub-business (administrative business tag / sub-business tag). The decision support request may also include a designation of associated information (budget system items, individual expenditure items, etc.) to be used as the subject of the decision, and further a designation of organizational system items.

[0142] The generation unit 24 references the judgment know-how DB 40 in response to a judgment support request. The generation unit 24 references the administrative business tags or minor business tags stored in the judgment know-how DB 40 based on at least the administrative business tags or minor business tags included in the judgment support request, and acquires one or more pieces of judgment know-how data related to the judgment know-how IDs associated with the tags. The generation unit 24 may also be configured to reference a combination of associated information and / or organizational structure items included in the judgment support request with administrative business tags or minor business tags, and acquire one or more pieces of judgment know-how data associated with the combination. For example, the appraisal know-how data acquired here includes at least one selected from appraisal perspectives, judgment axis tags (axis / specific subjects), appraisal rates, and appraisal amounts (budget amounts).

[0143] The generating unit 24 generates judgment support information based on one or more acquired judgment know-how data. Here, the judgment support information includes at least one or more budget amounts or an average budget amount obtained by averaging multiple budget amounts. The judgment support information also includes at least one or more assessed income amounts (appropriation amounts) or an average appropriation amount obtained by averaging multiple appropriation amounts. The budget amount, average budget amount, appropriation amount, or average appropriation amount may be classified by classification of ancillary items (details, individual expense items). The judgment support information also includes at least one or more target values ​​or an average target value obtained by averaging multiple target values. The target values ​​may be classified by indicators related to the target values.

[0144] FIG. 11 shows an example of the budget reference screen W20 displayed on the user terminal 3. By specifying target policy system information, the budget reference screen W20 displays a comparison of the budget amount for that policy system and the budget amount for the comparison target. On the budget reference screen W20, a task related to the XX project (task tag) in XX City (organizational system item) is specified as the target policy system (target task / project), and the budget amount aggregated by section associated with the target task / project is displayed in the target budget area W21. The budget reference screen W20 also displays the average budget amount aggregated by section for judgment know-how data that shares the task / project tag with the target task / project and has other organizational system items in the comparison budget area W22. The target budget area W21 and the comparison budget area W22 display a comparison using a graph with the budget amount (or average budget amount) on the horizontal axis and each section on the vertical axis. The comparison display can be in various formats, such as a graph, a table, or a numerical format, and is not limited to the display shown in the example.

[0145] Similarly, a comparison can be made of the amount of specific financial resources allocated.

[0146] The generation unit 24 generates judgment support information including a comparative display of target values ​​aggregated by indicators linked to the specified target business information and average target values ​​aggregated by indicators of judgment know-how data having other organizational system items common to the business tag of the target business. In the comparative display of target values, the comparison is displayed using a graph with the target value or average target value on the horizontal axis and each indicator on the vertical axis.

[0147] <3.15. Partnership Tag> A policy system (such as an administrative project or a minor project) under the jurisdiction of a certain administrative organization may be implemented in partnership with other organizations or projects. In this description, the partner organization, regardless of whether it is a public agency or a private organization, is defined as a partner entity. In addition, in this description, the partner business, regardless of whether it is the organization's own or another organization, is defined as a partner business. Partnering with a policy system contributes to the efficiency of the policy system and budget reductions, etc. In this embodiment, the decision support system 1 provides a proposal decision function regarding a partner business or partner project that is appropriate as a partner for a certain policy system.

[0148] In this embodiment, the judgment know-how DB 40 stores proposal know-how data for proposing partner entities and / or partner businesses. The proposal know-how data includes at least associated information and proposal know-how related to the partnership. The proposal know-how data may further include policy system information. Specifically, the proposal know-how data is configured to link proposal know-how related to the partnership to a combination of a policy system tag and a budget item system item.

[0149] In this embodiment, the proposed know-how has an alliance tag indicating at least one of an alliance entity and an alliance business. An alliance entity indicates a government agency or a private organization. If the alliance entity is a government organization, it can be identified by the organizational structure item. If the alliance entity is a private organization, it can be identified by the company name or company code. Note that the alliance entity may also be identified by the products, services, or solutions provided by the private organization, or the industry of the entity. An alliance tag indicating an alliance entity is a tag of a private company or a government organization such as a local government that has a track record of alliances for a certain policy system.

[0150] Affiliated projects can be identified by policy system information in the user's organization or in other organizations. Affiliated projects may also be identified by policy system tags corresponding to the policy system information. For example, if the policy system of the user's organization is an affiliated project, the affiliated project can be operated efficiently by mutually complementing the various resources, such as budgets and personnel, of the target policy system and the partner's policy system, or by integrating them into a single project. Affiliated projects can also be operated efficiently by mutually complementing the various resources of the policy systems of other local governments, etc., or by sharing work. Affiliated projects can be linked to the organizational system items that manage the project.

[0151] The partnership tag may be linked to geographic information of the partner entity or partner business. The geographic information is used to determine the partner by specifying the region of the partner entity or the region of the organization that manages the partner business. The partnership tag may also be linked to other information that is taken into consideration when proposing a partner.

[0152] The generation unit 24 generates decision support information including proposed know-how using an alliance tag in response to a decision support request related to an alliance. The decision support request includes a policy system tag of a target policy system and budget item system items. For example, if the decision support request includes administrative work related to civil engineering works and budget items related to construction costs, private companies that undertake civil engineering works are proposed to the user as alliance tags.

[0153] 12 shows an example of a display screen of a proposal screen W30 that provides decision support information including proposed know-how. The proposal screen W30 is displayed when a policy system is designated via the user terminal 3. In the illustrated example, the proposal screen W30 specifies the Airport Demand Recovery Promotion Project, which is an administrative project, and displays a Sub-Project area W31 that displays a sub-project (Inbound Demand Recovery Promotion Project) linked to the administrative project, and an Individual Expense Item area W32 that displays an individual expense item (XX Council contribution) linked to the sub-project.

[0154] The proposal screen W30 further displays proposal areas W33 and W34 that show decision support information based on the sub-project information (sub-project tag) corresponding to the sub-project area W31 and the individual expense items corresponding to the individual expense item area W32 or the budget account system items included therein. In the illustrated example, the proposal area W33 displays decision support information based on the financial resource tag, and the proposal area W34 displays decision support information based on the alliance tag. Note that the proposal areas may also display decision support information based on other decision axis tags.

[0155] Proposal area W34 proposes a partner (AAA Corporation), which offers taxi promotion measures as a solution, as a partner for a minor project (inbound demand recovery promotion project) linked to an individual expenditure item (XX Council contribution). This allows users to obtain information on suitable partners for the target policy system.

[0156] In addition, the proposal area W34 can also display decision support information that includes other policy systems as partnership tags. For example, inbound-related projects of one's own or other local governments that have the same subproject tags or budget item system items (subsections) as the target policy system may be proposed as partnership projects. Partner projects are not limited to those aimed at partnerships, and may be proposed and displayed for the purpose of providing information on the partner projects as a reference.

[0157] <3.16. Judgment Model> In this embodiment, the judgment know-how DB 40 can be configured to store a judgment model. The judgment model can output judgment know-how in response to input of at least associated information. Furthermore, the judgment model can output judgment know-how in response to input of a combination of policy system information and associated information. The judgment know-how includes at least one of the appraisal know-how, special asset know-how, classification know-how, and proposal know-how shown in FIG. 7 or FIG. 10. The judgment model can be substituted for judgment know-how data, and can be used in combination with judgment know-how data.

[0158] The generation unit 24 acquires a decision support request by specifying target policy system information for which decision support is required. Here, the decision support request includes at least accompanying information related to at least the specified target policy system information. The decision support request preferably further includes a policy system tag for the specified target policy system information. The generation unit 24 inputs the information included in the decision support request into a decision model and generates decision support information based on decision know-how output from the decision model.

[0159] The tag processing unit 23 can link the decision axis tag included in the decision support information to the accompanying information of the target policy system information by specifying the decision axis tag included in the decision support information or automatically.

[0160] The judgment model may be a machine learning model trained by machine learning using a data set in which the accompanying information is used as input data and the judgment know-how is used as output data. The input data may further include a policy system tag. The judgment model may be a neural network, a regression model, a decision tree, a k-nearest neighbor model, or the like.

[0161] For example, the first input data of the dataset may employ, as accompanying information, at least one associated item selected from budget item system items (subitem subsections), individual expenditure items, local government financial status survey items, and administrative goal system items. Furthermore, the associated items are not limited to structured data; text data generated by natural language processing of unstructured data (such as task and project names, subproject names, individual expenditure item names, and summaries) may also be used. Furthermore, the second input data of the dataset may employ, as policy system tags, policy tags, sub-policy tags, task and project tags, and sub-project tags. For example, the first output data of the dataset may employ, as judgment perspectives, judgment axis tags (assessment axis tags, financial resource tags, financial settlement statistics tags, public accounting tags, and indicator tags), and adjustment rates (assessment rates, allocation rates, and target value adjustment rates). Furthermore, the second output data of the dataset may further employ assessment amounts (budget amounts), revenue assessment amounts (allocation amounts), and target indicator values. The data set includes first input data and first output data, or includes first input data, first output data and second output data, or includes first input data, second input data and first output data, or includes first input data, second input data, first output data and second output data.

[0162] The judgment model is generated by machine learning using the above-mentioned datasets by a computer device. The generated judgment model is stored in the judgment know-how DB 40. The datasets can adopt output data suitable for each of the appraisal know-how, special asset know-how, classification know-how, and proposal know-how for different judgment know-how. Furthermore, the judgment model may be generated by machine learning using datasets suitable for different judgment know-how to generate an appraisal model, special asset model, classification model, and proposal model. The generation unit 24 selects one or more of the appraisal model, special asset model, classification model, and proposal model in response to a judgment support request, and generates judgment support information.

[0163] The dataset may include, for example, data in which the decision axis tags contained in the decision support information generated by the generation unit 24 are linked to policy system information by instructions from the user terminal 3, and data that are not linked, and additional learning of the decision model may be performed using these datasets.

[0164] The judgment model outputs one or more judgment axis tags in response to input information included in the judgment support request. Here, the judgment axis tags are output according to the likelihood calculated by the judgment model. The generation unit 24 generates, for example, judgment axis tags with likelihoods equal to or greater than a certain level as judgment support information.

[0165] The judgment model can output an estimated value of the correction rate by machine learning multiple correction rates included in the dataset. The generation unit 24 can input information included in the judgment support request to the judgment model and generate judgment support information including an estimated value of the correction rate output from the judgment model.

[0166] The judgment model can output estimated budget amounts (budget levels), estimated allocation amounts (appropriation levels), and estimated target values ​​(target value levels) by machine learning multiple assessment amounts (budget amounts), revenue assessment amounts (appropriation amounts), and target values ​​of indicators included in the dataset. The generation unit 24 can input information included in the judgment support request to the judgment model and generate judgment support information including the budget levels, appropriation levels, and target value levels that are output from the judgment model.

[0167] REFERENCE SIGNS LIST 1 Decision support system 2 Decision support device 21 Administrative data management unit 23 Tag processing unit 24 Generation unit 27 Output unit 28 Setting management unit 3 User terminal 4 Database 40 Decision know-how DB

Claims

1. A decision support system that supports decisions in the administration, which registers policy system information relating to a policy system including policies, measures, and administrative projects, and accompanying information associated with said policy system information, links decision know-how that indicates the implications or results of decisions on said policy system to at least said accompanying information and stores it in a database, and in response to a decision support request that includes at least the accompanying information for target policy system information requiring decision support, references said database and generates decision support information that includes the decision know-how that corresponds to the accompanying information included in the decision support request.

2. The decision support system described in claim 1, wherein the database stores the decision know-how linked to a combination of a policy system tag indicating a classification for the policy system and the accompanying information, and refers to the database in response to a decision support request including the policy system tag and the accompanying information of the target policy system information, and generates decision support information including the decision know-how corresponding to the combination of the policy system tag and the accompanying information included in the decision support request.

3. The judgment know-how includes a judgment axis tag or a judgment viewpoint and a correction rate for the value of the judgment subject, and in response to a judgment support request including at least accompanying information of the target policy system information, the judgment support system described in claim 1 or claim 2 refers to the database and generates judgment support information including the judgment axis tag or the judgment viewpoint corresponding to the accompanying information included in the judgment support request and the correction rate.

4. A decision support system as described in claim 3, which applies the decision axis tag or the decision perspective contained in the decision support information and the corresponding correction rate to the value of the decision subject of the target policy system information to obtain a correction value.

5. A decision support system as described in claim 3, which acquires a plurality of decision axis tags or decision perspectives corresponding to the accompanying information included in the decision support request and a plurality of corresponding revision rates, and generates the decision support information including an average revision rate obtained by averaging the plurality of revision rates.

6. The judgment know-how includes assessment know-how having an assessment perspective for the budget and an assessment axis tag, the accompanying information includes budget item system items which are classifications of budget items, the database stores the assessment know-how linked to combinations of policy system tags which indicate classifications for the policy system and the budget item system items, and in response to a judgment support request including the policy system tag and budget item system items of the target policy system information, the database is referenced and judgment support information including the assessment know-how corresponding to the combination of policy system tag and budget item system items included in the judgment support request is generated.

7. The judgment support system described in claim 6, wherein the appraisal know-how further includes an appraisal rate, and in response to a decision support request further including a requested budget amount for the target policy system information, decision support information including an appraisal rate related to an appraisal axis tag is generated, and the appraisal amount for the target policy system information is obtained by applying the appraisal rate related to the appraisal axis tag to the requested amount.

8. A decision support system as described in claim 6, wherein appraisal know-how including appraisal amounts is linked to the policy system tags and budget subject system items of the target policy system information and stored in a database.

9. A decision support system as described in claim 1 or claim 2, wherein the database stores budget item system items, policy system tags indicating policy system classifications, budget amounts, and organizational system items in association with each other, and in response to a decision support request including a policy system tag of the target policy system information, comparatively displays the budget amounts for each budget item system item in the policy system related to the policy system tag of other organizational system items.

10. A decision support system as described in claim 1 or claim 2, wherein the decision know-how includes special fund know-how having a funding source tag indicating a specific funding source, the accompanying information includes budget item system items which are classifications of budget items, the database stores the special fund know-how linked to combinations of policy system tags indicating classifications for the policy system and the budget item system items, and in response to a decision support request including the policy system tag and budget item system items of the target policy system information, references the database and generates decision support information including the special fund know-how corresponding to the combination of policy system tag and budget item system items included in the decision support request.

11. A decision support system as described in claim 1 or claim 2, wherein the judgment know-how includes classification know-how having subject tags related to local government financial situation surveys or public accounting, the accompanying information includes budget subject system items which are classifications of budget subjects, the database stores the classification know-how linked to combinations of policy system tags indicating classifications for the policy system and the budget subject system items, and in response to a decision support request including the policy system tags and budget subject system items of the target policy system information, references the database and generates decision support information including the classification know-how corresponding to the combination of policy system tags and budget subject system items included in the decision support request.

12. A decision support system as described in claim 1 or claim 2, wherein the decision know-how includes proposed know-how having an index tag related to an administrative goal system item, the accompanying information includes budget item system items which are classifications of budget items, the database stores the proposed know-how linked to combinations of policy system tags which indicate classifications for the policy system and the budget item system items, and in response to a decision support request including the policy system tag and budget item system items of the target policy system information, references the database and generates decision support information including the proposed know-how corresponding to the combination of policy system tag and budget item system items included in the decision support request.

13. A decision support system as described in claim 1 or claim 2, wherein the decision know-how includes proposal know-how having an alliance tag related to an alliance of the policy system, the accompanying information includes budget item system items which are classifications of budget items, the database stores the alliance tags linked to combinations of policy system tags indicating classifications for the policy system and the budget item system items, and in response to a decision support request including the policy system tag and budget item system items of the target policy system information, references the database and generates decision support information including the proposal know-how corresponding to the combination of policy system tag and budget item system items included in the decision support request.

14. A decision support system that supports decisions in administration, which registers policy system information relating to a policy system including policies, measures, and administrative projects, and accompanying information associated with the policy system information, has a decision model that outputs decision know-how that indicates suggestions or results of decisions regarding the policy system in response to input of the accompanying information, and in response to a decision support request that includes at least the accompanying information of the target policy system information requiring decision support, inputs the accompanying information into the decision model, and generates decision support information that includes the decision know-how that is output from the decision model.

15. A decision support method for supporting decisions in administration, wherein a computer executes the following processes: registering policy system information relating to a policy system including policies, measures, and administrative projects, and accompanying information associated with the policy system information; storing decision know-how indicating the implications or results of decisions on the policy system in a database, linked to at least the accompanying information; and referencing the database in response to a decision support request including at least the accompanying information of the target policy system information requiring decision support, and generating decision support information including the decision know-how corresponding to the accompanying information included in the decision support request.

16. A decision support program that supports administrative decisions, which registers policy system information relating to a policy system including policies, measures, and administrative projects, and accompanying information associated with the policy system information, stores decision know-how indicating the implications or results of decisions on the policy system in a database, linking it to at least the accompanying information, and, in response to a decision support request that includes at least the accompanying information for the target policy system information requiring decision support, references the database and generates decision support information that includes the decision know-how corresponding to the accompanying information included in the decision support request.

Images