特許第6941394号(P6941394)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社ログラスの特許一覧

特許6941394経営管理システム、経営管理方法及び経営管理プログラム
<>
  • 特許6941394-経営管理システム、経営管理方法及び経営管理プログラム 図000002
  • 特許6941394-経営管理システム、経営管理方法及び経営管理プログラム 図000003
  • 特許6941394-経営管理システム、経営管理方法及び経営管理プログラム 図000004
  • 特許6941394-経営管理システム、経営管理方法及び経営管理プログラム 図000005
  • 特許6941394-経営管理システム、経営管理方法及び経営管理プログラム 図000006
  • 特許6941394-経営管理システム、経営管理方法及び経営管理プログラム 図000007
  • 特許6941394-経営管理システム、経営管理方法及び経営管理プログラム 図000008
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】6941394
(24)【登録日】2021年9月8日
(45)【発行日】2021年9月29日
(54)【発明の名称】経営管理システム、経営管理方法及び経営管理プログラム
(51)【国際特許分類】
   G06Q 10/06 20120101AFI20210916BHJP
【FI】
   G06Q10/06 302
【請求項の数】7
【全頁数】14
(21)【出願番号】特願2020-159680(P2020-159680)
(22)【出願日】2020年9月24日
【審査請求日】2020年9月29日
【新規性喪失の例外の表示】特許法第30条第2項適用 [展示日]令和1年12月30日 [展示会名]関東ビジネスプランコンテスト「Startup Stage 2019」 [開催場所]東京都千代田区 [公開者]株式会社ログラス (他、特願2020−159680号における令和2年10月7日付け「新規性の喪失の例外証明書提出書」の別紙参照)
【早期審査対象出願】
(73)【特許権者】
【識別番号】519287932
【氏名又は名称】株式会社ログラス
(74)【代理人】
【識別番号】100137338
【弁理士】
【氏名又は名称】辻田 朋子
(72)【発明者】
【氏名】布川 友也
【審査官】 加舎 理紅子
(56)【参考文献】
【文献】 特開平11−259562(JP,A)
【文献】 特開2004−094943(JP,A)
【文献】 特開2005−327049(JP,A)
【文献】 特許第6496867(JP,B1)
【文献】 米国特許第07657471(US,B1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 − 99/00
(57)【特許請求の範囲】
【請求項1】
複数の単位を含む組織において、組織の予算計画を管理する経営管理システムであって、
前記経営管理システムは、処理部及び記憶部を備え、
前記記憶部は、科目を示す科目マスタ、単位を示す組織マスタ並びに前記科目、単位及び期間を属性として有する編成計画の計画マスタを有し、
前記処理部は、予算計画を行う対象とする複数の単位と、対象の期間を受け付け、
前記計画マスタに基づいて、受け付けた前記期間及び単位を対象とする予算計画を作成するための編成プロジェクトを作成し
記計画マスタから、受け付けた前記単位に対応する明細データを複製することで複数の単位別計画データを作成し、編成プロジェクトに対応付けて前記記憶部に格納し、
前記単位別計画データに対応する更新申請を前記単位毎に受け付けて、承認待ちの申請ステータスと対応付けて格納し、
前記更新申請の承認を受け付けて前記申請ステータスを承認済みに変更し、
前記承認が受け付けられた場合に、前記更新申請による更新前の前記単位別計画データを特定する為の更新前データを、前記更新申請に対応付けて前記記憶部に格納すると共に、受け付けた前記更新申請に基づいて前記単位別計画データを更新し、
前記編成プロジェクトが完了した場合、前記更新された前記単位別計画データに基づいて、前記計画マスタを上書きする、
経営管理システム。
【請求項2】
前記処理部は、前記単位別計画データ及び前記更新申請に基づいて、差分表示画面を表示処理して、表示処理結果を送信し、
前記差分表示画面を介して、前記更新申請の承認を受け付け可能に構成される、
請求項に記載の経営管理システム。
【請求項3】
前記差分表示画面は、前記科目及び前記期間を属性とする表形式で、明細を表示し、
前記明細は、前記更新申請に基づいて明細中に差分が生じた値、差分が生じていない値及びその差分を表示すると共に、それらを識別可能に表示し、
前記差分が生じていない値は、前記差分が生じた値及び/又は差分と比較して、薄墨で呈色される、
請求項に記載の経営管理システム。
【請求項4】
前記明細は、前記差分が生じた値、差分が生じていない値及び差分を色分け表示すると共に、前記差分が増加によるものか減少によるものかを色分け表示する、
請求項に記載の経営管理システム。
【請求項5】
前記更新申請を受け付ける際に、前記処理部は、前記更新申請を行う為のフォームにおいて、前記科目及び前記期間を属性とする表計算ソフト用データの入力を受け、
前記フォームに対応付けられた情報及び/又は表計算ソフト用データの入力を行うユーザの情報を更新申請設定データ、前記表計算ソフト用データの明細を更新申請明細データとする前記更新申請を受け付けると共に、
前記記憶部に、前記表計算ソフト用データを参照する為のパスを、前記更新申請と対応付けて格納する、
請求項1〜4の何れかに記載の経営管理システム。
【請求項6】
前記記憶部に格納された前記編成プロジェクト、前記科目マスタ及び前記組織マスタに基づいて、前記更新申請を受け付ける為の表計算ソフト用データであって、科目及び期間が入力され、前記科目及び期間の組み合わせに対して明細を入力する為の領域を有した表計算ソフト用データを生成する、
請求項1〜5の何れかに記載の経営管理システム。
【請求項7】
複数の単位を含む組織において、組織の予算計画を管理する経営管理方法であって、
経営管理システムの処理部が、予算計画を行う対象とする複数の単位と、対象の期間を受け付けるステップと、
科目、単位及び期間を属性として有する編成計画の計画マスタに基づいて、受け付けた前記期間及び単位を対象とする予算計画を作成するための編成プロジェクトを作成するステップと、
記計画マスタから受け付けた前記単位に対応する明細データを複製することで複数の単位別計画データを作成し、編成プロジェクトに対応付けて記憶部に格納するステップと、
前記単位別計画データに対応する更新申請を前記単位毎に受け付けて、承認待ちの申請ステータスと対応付けて格納するステップと、
前記更新申請の承認を受け付けて前記申請ステータスを承認済みに変更するステップと、
前記承認が受け付けられた場合に、前記更新申請による更新前の前記単位別計画データを特定する為の更新前データを、前記更新申請に対応付けて前記記憶部に格納すると共に、受け付けた前記更新申請に基づいて前記単位別計画データを更新するステップと、
前記編成プロジェクトが完了した場合、前記更新された前記単位別計画データに基づいて、前記計画マスタを上書きするステップと、を実行する、
経営管理方法。



【発明の詳細な説明】
【技術分野】
【0001】
本発明は、企業の経営管理を行う為の経営管理システム、経営管理方法及び経営管理プログラムに関する。
【背景技術】
【0002】
従来より、企業等の組織において、部署、部門、課、店舗等の単位毎に予算を設定し、また、予算と実績とを比較することで、経営目標の予実管理が行われている。組織全体の予算は、単位毎に、予算の作成、更新、差戻、承認等の手順を経ること登録される。そのため、このような予算は、ごく小規模な組織では一般的な表計算アプリケーションを利用して手作業でなされる場合があるが、組織が大きくなるにつれて複雑化する。
【0003】
特許文献1には、多次元データベースを用いて、保持してある明細データのバージョン管理を適切に行う技術が記載されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2009−15644号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、特許文献1の技術では、バージョン別の予算の明細について把握できるものの、そのバージョンが、どのような状態を意味するか把握することができない。そのため、複数の単位が予算を作成し、組織全体の予算を作成するような場合、各単位における状況がわからず、経営企画等の担当は、各単位に対して状況確認等の手続が発生することとなる。
【0006】
また、特許文献1の技術は、多次元データベースの管理を主眼としたものであり、組織における予算の作成時の効率化、ユーザビリティの向上の観点において、更なる改善の余地がある。
【0007】
上記事情を鑑みて、本発明は、複数の単位を有する組織において、効率的に予算を作成する為の技術を提供することを解決すべき課題とする。
【課題を解決するための手段】
【0008】
上記発明を解決するために、本発明は、複数の単位を含む組織において、組織の予算計画を管理する経営管理システムであって、
前記経営管理システムは、処理部及び記憶部を備え、
前記記憶部は、科目を示す科目マスタ、単位を示す組織マスタ並びに前記科目、単位及び期間を属性として有する編成計画の計画マスタを有し、
前記処理部は、前記計画マスタに基づいて、編成プロジェクトを作成し、作成した編成プロジェクトに、前記計画マスタから複製した複数の単位別計画データを対応付けて前記記憶部に格納し、
前記単位別計画データに対応する更新申請を受け付け、
前記更新申請による更新前の前記単位別計画データを特定する為の更新前データを、前記更新申請に対応付けて前記記憶部に格納し、
受け付けた前記更新申請に基づいて前記単位別計画データを更新し、
前記編成プロジェクトが完了した場合、前記更新された前記単位別計画データに基づいて、前記計画マスタを上書きする。
【0009】
また、本発明は、複数の単位を含む組織において、組織の予算計画を管理する経営管理方法であって、
経営管理システムの処理部が、科目、単位及び期間を属性として有する編成計画の計画マスタに基づいて、編成プロジェクトを作成し、作成した編成プロジェクトに、前記計画マスタから複製した複数の単位別計画データを対応付けて記憶部に格納するステップと、
前記単位別計画データに対応する更新申請を受け付けるステップと、
前記更新申請による更新前の前記単位別計画データを特定する為の更新前データを、前記更新申請に対応付けて前記記憶部に格納するステップと、
受け付けた前記更新申請に基づいて前記単位別計画データを更新するステップと、
前記編成プロジェクトが完了した場合、前記更新された前記単位別計画データに基づいて、前記計画マスタを上書きするステップと、を実行する。
【0010】
このような構成とすることで、編成プロジェクトに、計画マスタから複製した複数の単位別計画データを対応付けて格納することにより、単位別の編成プロジェクトに対する進行状況を管理可能となり、効率的に予算編成を実施することができる。
【0011】
本発明の好ましい形態では、前記更新前データの前記記憶部への格納は、前記更新申請が承認された場合に実行される。
また、本発明の好ましい形態では、前記更新申請に基づく前記単位別計画データの更新は、前記更新申請が承認された場合に実行される。
【0012】
このような構成とすることで、承認後に更新前データを記憶し、単位別計画データの更新を行うことができる。
【0013】
本発明の好ましい形態では、前記処理部は、前記単位別計画データ及び前記更新申請に基づいて、差分表示画面を表示処理して、表示処理結果を送信し、
前記差分表示画面を介して、前記更新申請の承認を受け付け可能に構成される。
【0014】
このような構成とすることで、承認を行うユーザは、差分を確認して承認/削除(あるいは差戻等)を行うことができる。
【0015】
本発明の好ましい形態では、前記差分表示画面は、前記科目及び前記期間を属性とする表形式で、明細を表示し、
前記明細は、前記更新申請に基づいて明細中に差分が生じた値、差分が生じていない値及びその差分を表示すると共に、それらを識別可能に表示し、
前記差分が生じていない値は、前記差分が生じた値及び/又は差分と比較して、薄墨で呈色される。
【0016】
前記明細は、前記差分が生じた値、差分が生じていない値及びその差分を色分け表示すると共に、前記差分が増加によるものか減少によるものかを色分け表示する。
【0017】
このような構成とすることで、差分確認画面上で、差分の確認が一目瞭然となる。
【0018】
本発明の好ましい形態では、前記更新申請を受け付ける際に、前記処理部は、前記更新申請を行う為のフォームにおいて、前記科目及び前記期間を属性とする表計算ソフト用データの入力を受け、
前記フォームに対応付けられた情報及び/又は表計算ソフト用データの入力を行うユーザの情報を更新申請設定データ、前記表計算ソフト用データの明細を更新申請明細データとする前記更新申請を受け付けると共に、
前記記憶部に、前記表計算ソフト用データを参照する為のパスを、前記更新申請と対応付けて格納する。
本発明の好ましい形態では、前記記憶部に格納された前記編成プロジェクト、前記科目マスタ及び前記組織マスタに基づいて、前記更新申請を受け付ける為の表計算ソフト用データであって、科目及び期間が入力され、前記科目及び期間の組み合わせに対して明細を入力する為の領域を有した表計算ソフト用データを生成する。
【0019】
このような構成とすることで、一般的な表計算ソフトを利用して、更新申請を行うことができる。
【発明の効果】
【0020】
本発明は、複数の単位を有する組織において、効率的に予算を作成する為の技術を提供することができる。
【図面の簡単な説明】
【0021】
図1】一実施形態のシステムの構成図。
図2】一実施形態の記憶部103に格納される情報を示すER図。
図3】一実施形態の計画マスタ、編成プロジェクトの明細データ(単位別計画データ)を示す図。
図4】一実施形態のシステムにおける予算編成を行う際の全体手順を示す図。
図5】一実施形態のシステムにおける編成プロジェクトを開始する際の処理手順を示す図。
図6】一実施形態のシステムにおける更新申請を行う際の処理手順を示す図。
図7】一実施形態のシステムにおける単位別計画データ、更新申請の明細データ差分表示画面を示す図。
【発明を実施するための形態】
【0022】
以下、添付図面を参照して、更に詳細に説明する。図面には好ましい実施形態が示されている。しかし、多くの異なる形態で実施されることが可能であり、本明細書に記載される実施形態に限定されない。
【0023】
例えば、本実施形態では経営管理システムの構成、動作等について説明するが、実行される方法、情報処理装置、コンピュータプログラム等によっても、同様の作用効果を奏することができる。本実施形態におけるプログラムは、コンピュータが読み取り可能な非一過性の記録媒体として提供されてもよいし、外部のサーバからダウンロード可能に提供されてもよいし、クライアント端末でその機能を実現する為に外部のコンピュータにおいて当該プログラムを起動させてもよい(いわゆるクラウドコンピューティング)。
【0024】
また、本実施形態において「部」とは、例えば、広義の回路によって実施されるハードウェア資源と、これらハードウェア資源によって具体的に実現され得るソフトウェアの情報処理とを合わせたものも含み得る。本実施形態において「情報」とは、例えば電圧・電流を表す信号値の物理的な値、0又は1で構成される2進数のビット集合体としての信号値の高低、又は量子的な重ね合わせ(いわゆる量子ビット)によって表され、広義の回路上で通信・演算が実行され得る。
【0025】
広義の回路とは、回路(Circuit)、回路類(Circuitry)、プロセッサ(Processor)及びメモリ(Memory)等を適宜組み合わせることによって実現される回路である。即ち、CPU(Central Processing Unit)、GPU(Graphics Processing Unit)LSI(Large Scale Integration)、ASIC(Application Specific Integrated Circuit)、FPGA(Field-Programmable Gate Array)等を含むものである。
【0026】
<システム構成>
図1は、一実施形態のシステムの構成を示すブロック図である。図1に示すように、経営管理システム1は、情報処理装置100及びユーザ端末装置200を備える。情報処理装置100及びユーザ端末装置200は、通信ネットワークNWを介して通信可能に構成されている。情報処理装置100は、サーバとして動作し、ユーザ端末装置200は、利用者が操作するクライアント端末である。
【0027】
通信ネットワークNWは、本実施形態では、IP(Internet Protocol)ネットワークであるが、通信プロトコルの種類に制限はなく、更に、ネットワークの種類、規模にも制限はない。
【0028】
<情報処理装置100>
情報処理装置100として、汎用のサーバ向けのコンピュータやパーソナルコンピュータ等を利用することが可能である。また、複数のコンピュータを用いて情報処理装置100を構成することも可能である。
【0029】
情報処理装置100は、通信部101、処理部102及び記憶部103を備え、組織の予算計画を管理する。通信部101は、通信ネットワークNWとの通信制御を実行して、情報処理装置100を動作させるために必要な入力や、動作結果に係る出力を行う通信インターフェースである。処理部102は、CPU等のプロセッサであって、本発明に係る経営管理プログラム、OSやブラウザソフト、その他のアプリケーションを実行することで、情報処理装置100の動作処理全体を制御する。記憶部103は、メモリ、ハードディスク等の記録装置又は記録媒体であって、本発明に係る経営管理プログラム及び、処理部102が経営管理プログラムに基づき処理を実行する際に利用するデータを記憶する。記憶部103は、情報処理装置100からアクセス可能なデータベース300を有していてもよく、これらデータの一部又は全部が、データベース300に記憶されてもよい。
【0030】
<ユーザ端末装置200>
ユーザ端末装置200として、パーソナルコンピュータ、スマートフォン及びタブレット端末等を利用することができる。ユーザ端末装置200は、情報処理装置100に対してリクエストを行い、レスポンスを受け取る為のアプリケーション(典型的には、ウェブブラウザ)を有する。
【0031】
また、ユーザ端末装置200も情報処理装置100と同様に、通信インターフェースとしての通信部と、CPU等のプロセッサである処理部と、メモリ、ハードディスク等の記録装置又は記録媒体である記憶部を備えると共に、マウスやキーボード、タッチパネル等の操作入力部と、モニタやディスプレイ等の表示部と、を備える。
【0032】
予算計画の管理は、例えば、経営企画等の単位に所属し、予算について意思決定を行う主体(以下、管理者と呼称する)及び、各単位に属し、予算案を提出して管理者による承認を得る主体(以下、作成者)が、それぞれ別個のユーザ端末装置200を利用することで実行され得る。これら主体を区別する場合、管理者によって操作されるユーザ端末装置200を管理者端末装置201、作成者によって操作されるユーザ端末装置200を作成者端末装置202と呼称する。
【0033】
本実施形態では、ユーザ端末装置200のウェブブラウザを介して予実管理のためのウェブサイトへアクセスし、情報処理装置100による予算を行う。情報処理装置100は、ユーザ端末装置200からのリクエストに基づいて処理を実行すると共に、ウェブサイトを表示処理して、表示処理結果をユーザ端末装置200に返送する。ウェブサイトは、ユーザがサービスにログインを行うことで利用され、ログインによって特定されるユーザ情報と、編成プロジェクトの状態に基づいて、ユーザの権限に応じた操作がリクエスト可能となる。また、適宜、処理結果に関するメタデータ(後述の設定データ)として、操作を行ったユーザが対応付けて格納される。
【0034】
<記憶部に記憶された情報>
記憶部103は、予め、ユーザ情報、組織情報、科目マスタ、年月マスタ及び、計画マスタを記憶している。例えば、ユーザ情報や組織情報、科目マスタ、計画マスタ等は、管理者により登録・更新され得る。
【0035】
ユーザ情報は、個々の利用者に関する情報であって、ユーザIDと共に、ユーザの名称、所属する組織(組織ID)、単位(単位ID)等を有する。組織情報は、組織IDと、組織マスタIDと、を有する。また、組織情報は、更に、組織が有する個々の単位の単位ID及び名称並びに単位間の親子関係を、組織マスタIDと対応付けて有する。これにより、組織マスタ情報は、組織における単位のツリー構造、組織図を示す。
【0036】
科目マスタは、科目データとして、勘定科目データ及び補助科目データを有する。科目データ(勘定科目データ)は、予算に利用する勘定科目の勘定科目ID、名称、科目が収益か費用かを示す科目区分及び表示順序を組織IDと対応付けた情報である。科目データ(補助科目データ)は、補助科目ID、名称、親となる勘定科目の勘定科目ID及び表示順序を組織IDと対応付けた情報である。なお、科目マスタは、予めプリセットされたものを利用してもよいし、組織毎に登録してもよい。年月マスタは、年月マスタIDとそれぞれの年月を対応付けた情報である。
【0037】
なお、情報処理装置100は、管理者端末装置201を介して、実績データを受け付け可能に構成されてもよく、これにより、予実管理を行うことができる。実績データは、例えば、実績ID、勘定科目ID、補助科目ID、年月マスタID、単位ID、組織ID、値(実績値)等を有する。
【0038】
<ER図>
図2は、記憶部103に格納される情報を示すER図の一例である。本実施形態では、計画マスタは、設定データ及び明細データを含む。計画マスタの設定データは、計画マスタのメタデータを示すものであり、計画マスタID、計画マスタを複製した場合の複製元の計画マスタを示すオリジン計画マスタID、名称(例えば「2020年度見込み」等)、計画の値が見込みか/予算かを示す為の設定であるタイプ、最終更新日時、作成日時及び、組織IDを有する。
【0039】
計画マスタの明細データは、計画マスタに含まれた値を示すものであり、計画マスタ明細ID、計画マスタID、勘定科目ID、補助科目ID、単位ID、年月マスタID、値、組織IDを有する。計画マスタは、単位及び期間を属性として有する値を含む。
【0040】
図3(a)は、計画マスタの一例を示す図である。図示例は、「A部署」及び「B部署」なる単位における「売上高」及び「売上原価」なる科目について、2020年4月〜2021年3月の月次の値を格納した計画マスタである。
【0041】
<予算作成の全体手順>
図4は、情報処理装置100を用いて予算の作成を行う際の全体手順を示す図である。予算の作成を行う場合、まず、情報処理装置100は、管理者端末装置201を介して、予算の対象とする計画マスタの指定を受け付ける(ステップS401)。この際、例えば、既に記憶部103に格納された計画マスタを複製して計画マスタを作成し、複製した計画マスタを指定して予算の作成を行ってもよい。この場合、計画マスタの設定データは、オリジン計画マスタIDとして複製元の計画マスタIDを含む。
【0042】
次いで、情報処理装置100は、管理者端末装置201を介して、編成プロジェクトの開始を受け付ける(ステップS402)。情報処理装置100は、編成プロジェクトが完了するまで(ステップS403でNO)、更新申請に関する処理を実行する(ステップS404)。そして、情報処理装置100は、編成プロジェクトが完了した場合(ステップS403でYES)、更新された単位別計画データに基づいて、指定された計画マスタを更新する(S405)。計画マスタの更新は、例えば、計画マスタの明細データを、更新された単位別計画データに基づいて上書きする処理である。
【0043】
<編成プロジェクトの開始>
図5は、情報処理装置100を用いて編成プロジェクトを開始する際の処理手順を示す図である。ステップS402において、まず、情報処理装置100は、管理者端末装置201を介して、予算の対象とする編成対象期間の指定を受け付ける(ステップS501)。また、情報処理装置100は、管理者端末装置201を介して、予算の対象とする単位の指定を受け付ける(ステップS502)。そして、情報処理装置100は、ステップS501及びS502にて指定された編成対象期間について、編成プロジェクトを生成する(ステップS503)。
【0044】
図3(b)の例では、図3(a)で例示する計画マスタから、編成対象期間の開始年月を「2020年4月」、終了年月を「2020年6月」として指定し(ステップS501)、単位として「A部署」及び「B部署」(全単位)を指定した(ステップS502)場合の編成プロジェクト(に含まれる明細データの集合)を示す。
【0045】
図2に示すように、本実施形態では、編成プロジェクトは、設定データ及び明細データを含む。編成プロジェクトの設定データは、編成プロジェクトのメタデータを示すものであり、編成プロジェクトID、指定された計画マスタの計画マスタID、組織マスタID、名称(例えば「2020年度4月見込み」等)、編成対象期間の開始年月(年月マスタID)、終了年月(年月マスタID)、編成計画の(現実の)開始日時、(現実の)終了日時、終了予定日時、進行中/完了等の状態を示す編成ステータス、編成バージョン、開始ユーザ、最終更新日時、作成日時及び、組織ID、取り込み済み最終実績年月を有する。本実施形態では、取り込み済み最終実績年月は、実績データを取り込み済みの年月マスタIDに基づいて設定され得る。編成ステータスは、変更された場合、元に戻せない構成が好ましい。
【0046】
情報処理装置100は、ステップS503において、編成プロジェクトを生成すると、指定された計画マスタから、指定された部署について、その明細データを複製して、単位別計画データを生成する。編成プロジェクトの明細データは、編成プロジェクトに含まれた値(進行中の編成プロジェクトの場合は見込み、完了の場合は予算)を示すものであり、編成プロジェクト明細ID、編成プロジェクトID、勘定科目ID、補助科目ID、単位ID、年月マスタID、値、組織IDを有する。
【0047】
編成プロジェクトの明細データは、表計算ソフト用データ上の個々のセルの値を示すものであるが、これを単位別にまとめたものを単位別生成データとする。即ち、本実施形態では、編成プロジェクト明細ID、編成プロジェクトID及び単位IDが共通する編成プロジェクトの明細データが、単位別計画データとなる。
【0048】
図3(c)では、図3(b)で例示する編成プロジェクトを、単位別(「A部署」及び「B部署」)にまとめた単位別計画データを示す。
【0049】
<更新申請用シートの生成>
そして、情報処理装置100は、管理者端末装置201を介して、部署別の更新申請用シートの作成リクエストを受け付け、更新申請用シートを提供する(ステップS504)。情報処理装置100は、記憶部103に格納された編成プロジェクト及び科目マスタに基づいて、更新申請を受け付ける為の表計算ソフト用データであって、科目及び期間が入力され、科目及び期間の組み合わせに対して明細を入力する為の領域を有した更新申請用シートを生成する。また、科目マスタに基づいて、勘定科目のレコードを入力する明細部分には、補助科目のレコードを入力する明細部分の値に基づいて集計がなされる関数が埋め込まれてもよい。更新申請用シートは、例えば、MICROSOFT EXCEL(登録商標)等のクライアントアプリケーション用のファイルや、googleスプレッドシート等のクラウドアプリケーションのURL等の形式で、提供される。この際、記憶部103に実績値が格納されており、編成対象期間の開始年月以降の年月における実績値が取り込まれているのであれば、更新申請用シートに反映してよい。
【0050】
<編成プロジェクトの開始通知>
情報処理装置100は、ユーザ情報に基づいて作成者となる該当部署のユーザに対して、更新申請の開始を通知してよい。なお、この際に、生成した更新申請用シートをダウンロードあるいは、ウェブブラウザで表示する為のURLを通知に含めてよい。また、更新申請用シートは、作成者端末装置202から作成リクエスト可能であってもよい。
【0051】
<更新申請の受付>
図6は、情報処理装置100を用いて更新申請を行う際の処理手順を示す図である。なお、以下の更新申請に関する処理は、単位別に実行される。ステップS404において、まず、情報処理装置100は、ある単位に属するユーザの操作する作成者端末装置202を介して、当該単位の単位別計画データに対応した更新申請を受け付ける(ステップS601)。情報処理装置100は、受け付けた更新申請を記憶部103に記憶する。
【0052】
情報処理装置100は、更新申請を受け付ける為のフォームを、作成者端末装置202に表示させる。作成者端末装置202は、表示されたフォームにおいて、更新申請のための明細の入力(編集)を行った更新申請用シートを入力する。ファイルを入力する場合は、フォームに設けられたアップローダーを介して更新申請用シートが情報処理装置100へ送信され、クラウドアプリケーションの場合は更新申請用シートのURLを入力する。
【0053】
ここで、フォームを介して、編成プロジェクトIDといったフォームに対応付けられた情報及び/又は、例えばユーザID等表計算ソフト用データの入力を行うユーザのユーザ情報が情報処理装置100に送信され、これらは、更新申請の設定データとして記憶される。また、更新申請用シートの明細は、更新申請の明細データとして記憶される。更に、更新申請用シートがファイルの場合は、記憶部103にファイルを格納する。更新申請用シートがURLにより指定される場合は、記憶部103にURLを格納する。
【0054】
図2に示すように、本実施形態では、更新申請は、設定データ及び明細データを含む。更新申請の設定データは、更新申請のメタデータを示すものであり、更新申請ID、更新申請が対象とする編成プロジェクトの編成プロジェクトID、名称(例えば「2020年度4月見込みA部署〇〇〇〇更新申請」等)、承認待ち/承認済み等の状態を示す申請ステータス、更新申請を行った作成者の単位ID、作成者のユーザID、更新申請の作成(申請)日時、承認ユーザのユーザID、承認日時、組織ID、更新申請タイプ及びパスを有する。更新申請タイプは、例えば、MICROSOFT EXCEL(登録商標)やgoogleスプレッドシート等、更新申請を行うツール(アプリケーション)について示すものであり、パスは、記憶部103に格納した更新申請用シートファイルを参照する為のパス、あるいはクラウドアプリケーションのURLであって、受け付けた更新申請用シートと更新申請を対応付けて格納する情報である。申請ステータスは、変更された場合元に戻せないのが好ましい。
【0055】
更新申請の明細データは、更新申請された明細の値を示すものであり、更新申請明細ID、更新申請ID、勘定科目ID、補助科目ID、単位ID、年月マスタID、値、組織IDを有する。
【0056】
<更新申請の承認>
ステップS601において、更新申請を受け付けると、更新申請の承認/差戻が行われる(ステップS602)。図7(a)は単位別計画データの一例を示す図であり、図7(b)は更新申請の明細データの一例を示す図である。ここで、「売上高」の科目には補助科目(収益)である「売上高広告運用」の値が入力され、「売上原価」の科目には補助科目(費用)である「給与手当原価」+「外注費原価」の値の合計が入力され、「売上純利益」の科目には「売上高」から「売上原価」を引いたが値が入力される。この明細データは、「売上高広告運用」の各年月レコードが、各期間50加算されて、更新申請されたとする。
【0057】
情報処理装置100は、更新申請を受け付けると、単位別計画データ及び更新申請に基づいて差分表示画面を表示処理して、表示処理結果を管理者端末装置201送信する。そして、管理者端末装置201において表示された差分表示画面を介して、更新申請の承認を受け付け可能に構成される。
【0058】
<差分の画面表示例>
図7(c)は、差分表示画面の画面表示例である。差分表示画面は、科目及び期間を属性とする表形式で、明細を表示する画面である。明細には、更新申請に基づいて明細中に差分が生じた値、差分が生じていない値及びその差分が表示されると共に、それらが識別可能に表示される(例えば、差分が生じた値:黒(変化なし)、差分が生じていない値:グレー、差分値(加算):緑、差分値(減算):赤)。ここで、差分が生じていない値は、前記差分が生じた値及び/又は差分と比較して、薄墨で呈色される。
【0059】
また、明細の背景色について、図示例では、補助科目の入力によって値が入力される科目の見出し及び明細には、補助科目の見出し及び明細と異なる背景色が付される(例えば青)。更に、差分が生じていない値が入力された明細には、更に異なる背景色が付される(例えばグレー)。ここで、差分が生じた値が入力された明細には、更に異なる背景色が付される(例えば黄)。
【0060】
管理者は、差分表示画面を確認して、作成者から申請された更新申請の内容を把握し、その承認又は差戻を行う。差戻を行う場合(ステップS602でNO)、ステップS403に戻り、編成プロジェクトが完了するまで、更新申請を待ち受ける。更新申請が差し戻された場合、記憶部103に格納されていた差し戻された更新申請の設定データ及び明細データを削除する。
【0061】
更新申請を承認すれば(ステップS602でYES)、ステップS603に進む。更新申請が承認されると、更新申請による更新前の単位別計画データを特定する為の更新前データを、更新申請に対応付けて記憶部103に格納する(ステップS603)。図7(c)の画面表示例は、承認後の画面を示し、ステータスが「完了」となっている。画面表示例において提出元シート部分が選択操作されると、更新申請のパスに基づいて、ファイルがダウンロード又はデータへのアクセスが行われる。
【0062】
図2に示すように、本実施形態では、更新前データは、紐づけられた更新申請が承認前(更新前)の単位別計画データの値を示すものであり、編成プロジェクト明細ID、編成プロジェクトID、科目ID、補助科目ID、単位ID、年月マスタID、値、組織ID、更新申請IDを有する。
【0063】
そして、受け付けた更新申請に基づいて単位別計画データを更新する(ステップS604)。単位別計画データが更新されると、編成プロジェクトの設定データにおいて、編成バージョンが加算される。管理者は、この編成バージョンを確認することで、編成プロジェクトのおよその進行状態を把握できる。また、最終更新日時がアップデートされる。
【符号の説明】
【0064】
1 :経営管理システム
100 :情報処理装置
101 :通信部
102 :処理部
103 :記憶部
200 :ユーザ端末装置
201 :管理者端末装置
202 :作成者端末装置
300 :データベース
NW :通信ネットワーク
【要約】      (修正有)
【課題】複数の単位を有する組織において、効率的に予算を作成する為の技術を提供する経営管理システム、経営管理方法及び経営管理プログラムを提供する。
【解決手段】複数の単位を含む組織において組織の予算計画を管理する経営管理システムは、記憶部と、処理部とを備える。処理部は、計画マスタに基づいて、編成プロジェクトを作成し、作成した編成プロジェクトに、計画マスタから複製した複数の単位別計画データを対応付けて記憶部に格納し、単位別計画データに対応する更新申請を受け付け、更新申請による更新前の単位別計画データを特定する為の更新前データを、更新申請に対応付けて記憶部に格納し、受け付けた更新申請に基づいて単位別計画データを更新し、編成プロジェクトが完了した場合、更新された単位別計画データに基づいて、計画マスタを上書きする。
【選択図】図4
図1
図2
図3
図4
図5
図6
図7