JP2000268084A - 統合業務パッケージソフト導入計画立案支援システム - Google Patents

Abstract

(57)【要約】 【課題】 ＥＲＰパッケージを導入する際に導入計画段
階でＥＲＰパッケージに対する標準業務利用の部分とア
ドオン部分との切り分けを支援する。 【解決手段】 標準業務テーブル１４はＥＲＰパッケー
ジが提供する標準業務の仕様を格納する。サーバ７，ク
ライアント８の処理装置１，６は、標準業務テーブル１
４を表示し、入力装置３を介して各業務について標準業
務の仕様通りに標準業務を利用するか、標準業務を利用
しないか、標準業務の仕様を修正開発した上で利用する
か、標準業務以外の業務を追加開発するのかの区分が入
力されたとき業務の識別子に対応するこの区分を新業務
テーブル１６に保存する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、生産、販売、購
買、会計、人事などの企業活動に関する業務を統合して
管理運営するためのソフトウエアであるＥＲＰ（Ｅｎｔ
ｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎ
ｇ）パッケージソフト（統合業務パッケージソフト）を
導入する際に導入計画の立案を支援するシステムに関す
る。

【０００２】

【従来の技術】企業が情報システムを構築するとき、そ
の企業独自の情報システムを設計し開発するケースと、
ＥＲＰパッケージソフトなど既存のパッケージソフトを
購入し、これを利用して情報システムを構築するケース
とがある。既存のパッケージを利用する場合でも一般に
その企業独自の業務を追加したり、ＥＲＰパッケージソ
フトが提供するモジュールの一部を修正するなど、いわ
ゆるアドオンの部分の開発が発生する。

【０００３】

【発明が解決しようとする課題】ＥＲＰパッケージソフ
トを利用するに際して、ＥＲＰパッケージソフトのどの
部分が適用可能か、どの部分が適用不可か、どの部分に
修正開発が生じるのか、追加開発する業務は何かなど、
アドオン範囲の切り分けをする必要がある。しかし導入
計画フェーズにおいてはこのようなアドオン範囲の切り
分けを支援するツールはなく、設計フェーズになってか
らＳＥ（システムエンジニア）がＥＲＰパッケージのデ
モなどを見ながら紙の上でこのような切り分けを行って
いる。一般にアドオンの切り分けの判断は導入するＥＲ
Ｐパッケージソフトを熟知していないと難しく、またア
ドオンの開発工数の見積もりも複雑であり、計画段階と
実際の構築段階とのずれが多数発生していた。

【０００４】本発明の目的は、導入計画段階でアドオン
範囲の切り分けを支援するシステムを提供することにあ
る。

【０００５】

【課題を解決するための手段】本発明は、統合業務パッ
ケージソフトが提供する標準業務の仕様を格納する標準
業務テーブル手段と、この標準業務テーブルを表示装置
上に表示し、各業務について標準業務の仕様通りに標準
業務を利用するか、標準業務を利用しないか、標準業務
の仕様を修正開発した上で利用するか、標準業務以外の
仕様の業務を追加開発するのかの区分が入力されたと
き、業務の識別子に対応するその区分を新業務テーブル
として記憶装置に保存する処理手段とを有する統合業務
パッケージソフト導入計画立案支援システムを特徴とす
る。ＥＲＰパッケージソフトの導入に伴って稼動が予定
される新業務が標準業務利用か、修正開発業務か、追加
開発業務かの明確な切り分けが行われるので、概算導入
費用を計算する場合にはこれらの業務区分に従ってそれ
ぞれ標準導入費用、修正開発費用及び追加開発費用を計
算すればよい。また開発プロジェクトの計画を立案する
場合にも、標準業務、修正開発業務、追加開発業務の各
々について開発体制と開発日程を立案すればよい。

【０００６】

【発明の実施の形態】以下本発明の実施形態について図
面を用いて説明する。

【０００７】図１は、本実施形態の統合業務パッケージ
ソフト導入計画立案支援システムの構成を示す図であ
る。システムはＥＲＰを利用する企業に設置されるサー
バ７とクライアント８、およびＥＲＰのベンダ側に設置
されるサーバ１００とから構成される。サーバ７と複数
のクライアント８とはＬＡＮ（ローカルエリアネットワ
ーク）などのネットワーク９を介して接続される。サー
バ１００は広域のネットワーク９０及びネットワーク９
を介してサーバ７及びクライアント８と接続される。サ
ーバ７は処理装置１と記憶装置２から構成される。また
クライアント８は処理装置６、入力装置３、表示装置４
及び印刷装置５から構成される。

【０００８】記憶装置２は図示するように標準プロジェ
クトＤＢ１１から導入事例ＤＢ２８までのＤＢ（データ
ベース）又はテーブルを格納する。標準プロジェクトＤ
Ｂ１１は、標準の開発体制に関するテーブル、標準の作
業項目についてのスケジュールに関するテーブル、標準
のガイドライン項目に関するテーブル及び標準のプロダ
クト（生産物）に関するテーブルを含む。新プロジェク
トＤＢ１２は、標準プロジェクトＤＢ１１を基にして作
成され、ＥＲＰの導入計画を作成するための実際の体制
を格納するテーブル、導入計画作成のスケジュールを格
納するテーブル及び大方針となるガイドラインを格納す
るテーブルを含む。目的／目標テーブル１３は、統合業
務パッケージソフト導入の目的及び目標を格納する。標
準業務テーブル１４は、統合業務パッケージソフトがサ
ポートしている標準業務の仕様を格納する。現状業務テ
ーブル１５は、統合業務パッケージソフトがサポートす
る標準業務を基にして当該企業の現状業務を整理区分し
たテーブルである。新業務テーブル１６は、統合業務パ
ッケージソフト導入後に対象となる新業務について標準
業務を基にして区分し業務仕様を記載するテーブルであ
る。変化点テーブル１７は、新業務が現状業務に比べて
変更される部分について記述するテーブルである。

【０００９】標準価値テーブル１８は、統合業務パッケ
ージソフトがサポートする標準業務についてその価値を
格納する。効果算定テーブル１９は、現状業務から新業
務に移行したときに得られる価値の増加、すなわち効果
を格納する。標準導入費用テーブル２０は、統合業務パ
ッケージソフトがサポートしている標準業務をそのまま
導入するときにかかる標準の導入費用を格納する。新導
入費用ＤＢ２１は、統合業務パッケージソフトの導入に
伴って発生する費用を格納するＤＢであり、標準費用を
格納するテーブル、修正開発費用を格納するテーブル及
び追加開発費用を格納するテーブルを含む。

【００１０】標準後続プロジェクトＤＢ２２は、統合業
務パッケージソフトの導入プロジェクトについて標準の
開発期間及び開発体制を格納する。新後続プロジェクト
ＤＢ２３は、導入プロジェクトを実行するための実際の
開発体制を格納するテーブル及び開発日程を格納するテ
ーブルを含む。標準計画書テーブル２４は、標準の統合
業務パッケージソフト導入計画書を構成する項目を格納
する。新計画書ＤＢ２５は、ＥＲＰ導入のための実際の
計画書の情報を格納し、標準項目の採否や導入計画立案
に伴って作成される生産物のテーブル以外のテキスト情
報を含む。進捗管理テーブル２６は、導入計画に伴って
作成されるテーブルの作成進捗状況を示すテーブルであ
る。作業手順案内テーブル２７は、導入計画に伴う作業
項目、作業の手順などを説明するプログラムの名称を列
挙するテーブルである。導入事例ＤＢ２８は、導入事例
を集めたＤＢであり、修正開発事例を集めたテーブル、
追加開発事例を集めたテーブル、修正開発プロジェクト
の事例を有するテーブル及び追加開発プロジェクトの事
例を有するテーブルを含む。

【００１１】表示装置４は、現状業務整理画面、新業務
定義画面など計画作成作業をするための案内画面及び入
力結果を表示する装置である。入力装置３は、表示画面
上のボタンを指示したりデータを入力するためのキーボ
ード、マウスなどの装置である。印刷装置５は、導入計
画の計画書などを印刷する装置である。

【００１２】図２は、処理装置１または処理装置６のメ
モリに格納され処理装置によって実行されるプログラム
・モジュールをクローズアップして示すシステム構成図
である。図１の処理装置１、処理装置６及びネットワー
ク９を含む点線枠の部分をまとめて処理装置１，６とし
て図示する。サーバ７は図１に示すＤＢ及びテーブルを
管理するＤＢＭＳ（データベースマネージメントシステ
ム）を含む。また各クライアント８は、入力装置３及び
表示装置４と利用者との間のマンマシン・インタフェー
ス部となるＧＵＩ（グラフィカルユーザインタフェー
ス）のプログラムを含む。プロジェクト発足支援モジュ
ール３１から作業手順案内モジュール４２までのプログ
ラムは、サーバ７の処理装置１で実行され、各クライア
ント８がこれらのプログラムを共用してもよい。あるい
はサーバ７から各クライアント８にダウンロードされ、
各クライアント８の処理装置６によつて実行されてもよ
い。

【００１３】プロジェクト発足支援モジュール３１は、
標準プロジェクトＤＢ１１を読み込み、導入計画を作成
するための実際の体制、スケジュール及びガイドライン
を入力して新プロジェクトＤＢ１２を作成する。目的／
目標設定モジュール３２は、入力装置３を介して入力さ
れた統合業務パッケージソフト導入の目的／目標を目的
／目標テーブル１３に格納する。現状業務整理支援モジ
ュール３３は、標準業務テーブル１４を読み込み、現状
業務整理画面を作成して表示装置４上に表示する。現状
業務の整理区分が入力されると、現状業務テーブル１５
を作成して記憶装置２に格納する。新業務定義支援モジ
ュール３４は、標準業務テーブル１４を読み込み、新業
務定義画面を作成して表示装置４上に表示する。新業務
の入力及び区分が行われると、新業務テーブル１６を作
成して記憶装置２に格納する。変化点整理支援モジュー
ル３５は、現状業務テーブル１５及び新業務テーブル１
６を読み込み、その内容を表示装置４上に表示する。入
力装置３を介して新業務が現状業務に比べて変更される
部分のコメントが入力されると、その結果から変化点テ
ーブル１７を作成して記憶装置２に格納する。

【００１４】効果算定モジュール３６は、標準価値テー
ブル１８、現状業務テーブル１５及び新業務テーブル１
６を読み込み、標準価値テーブル１８の価値及び現状業
務テーブル１５を業務に対応させて表示する。新業務の
価値が入力されると、現状業務の価値と新業務の価値か
ら各業務についてＥＲＰ導入の効果を計算して効果算定
テーブル１９に格納する。導入費用見積支援モジュール
３７は、新業務テーブル１６を読み込み、標準業務を利
用する業務については標準導入費用テーブル２０に基づ
いて入力されたサーバ／クライアントの台数から標準導
入費用を計算して新導入費用ＤＢ２１に格納する。また
標準業務を修正開発する業務については、標準業務テー
ブル１４及び導入事例ＤＢ２８を参照し、入力された修
正開発費用を新導入費用ＤＢ２１に格納する。また追加
開発する業務については、導入事例ＤＢ２８を参照し、
入力された追加開発費用を新導入費用ＤＢ２１に格納す
る。

【００１５】後続プロジェクト計画モジュール３８は、
新業務テーブル１６を読み込み、標準業務を利用する業
務については標準後続プロジェクトＤＢ２２を参照し入
力された標準業務の開発体制と開発日程を新後続プロジ
ェクトＤＢ２３に格納する。また修正開発業務及び追加
開発業務については、それぞれ導入事例ＤＢ２８を参照
し、入力された修正開発業務及び追加開発業務の開発体
制と開発日程を新後続プロジェクトＤＢ２３に格納す
る。

【００１６】計画書作成支援モジュール３９は、標準計
画書テーブル２４を読み込んで表示し、計画書の項目の
採否が入力されると、新計画書ＤＢ２５を作成して記憶
装置２に格納する。また計画書中の表紙、目次、始めに
の部分が入力されると新計画書ＤＢ２５に格納する。次
に新計画書ＤＢ２５に格納された項目の採否に従って該
当するテーブルを記憶装置２から集め、計画書を合成し
て印刷装置５上に出力する。進捗管理モジュール４０
は、新プロジェクトＤＢ１２中のスケジュールテーブル
から作業項目を読み込み、標準プロジェクトＤＢ１１の
標準生産物テーブルを参照して生産物となる各テーブル
が作成済みか否かを判定し、その結果を進捗管理テーブ
ル２６に格納する。下流ＣＡＳＥ連動モジュール４１
は、図示しないＣＡＳＥツールから問い合わせがあった
とき、指定されたテーブルから該当するデータを引き出
してＣＡＳＥツールに回答する。作業手順案内モジュー
ル４２は、作業手順案内テーブル２７を読み込んで作業
項目に対応するプログラムのファイル名称を列挙するメ
ニューを表示する。いずれかの作業項目が選択される
と、該当するプログラムを読み込んで起動し、作業手順
の案内情報を表示する。マルチ拠点連動モジュール４３
は、いずれかのモジュールの処理に介入して入力された
指令やデータを当該クライアント８の該当するモジュー
ルに入力するとともに他クライアント８のマルチ拠点連
動モジュール４３を介して該当モジュールに入力し、複
数のクライアント８が同一モジュールの実行、同一表示
画面の共用を実現する。アップデートモジュール４４
は、クライアント８が通信モジュール４５及びネットワ
ーク９０を介してサーバ１００と通信し、サーバ１００
に用意された最新のテーブルのメニューを表示装置４上
に表示する。いずれかの項目が選択されると、サーバ１
００へ送信し、サーバ１００から受信したテーブルを記
憶装置２に保存する。通信モジュール４５は、処理装置
６に設けられ、ネットワーク９０を介してクライアント
８がサーバ１００と通信するために用いられる。

【００１７】プロジェクト発足支援モジュール３１から
作業手順案内モジュール４２までのプログラムを記憶媒
体に格納し、処理装置１又は処理装置６に接続される駆
動装置を介して処理装置１又は処理装置６に読み込まれ
るか、他の計算機に接続される駆動装置、他の計算機、
ネットワークを介して処理装置１又は処理装置６に伝送
され、処理装置１又は処理装置６によつて実行可能であ
る。

【００１８】図３は、新プロジェクトＤＢ１２中の体制
テーブルのデータ構成を示す図である。ここで体制とは
統合業務パッケージ導入計画立案の作業に係わる人員の
体制である。「役割」は各メンバの役割を示す情報でプ
ロジェクトマネージャー、プロジェクトリーダー、プロ
ジェクトメンバーなどの役割がある。「氏名」は各メン
バの氏名の情報である。「部署」は各メンバの所属部署
の情報である。「内線」は各メンバの電話の内線番号の
情報である。なお標準プロジェクトＤＢ１１中の体制テ
ーブルは、「役割」のみが設定されている。

【００１９】図４は、新プロジェクトＤＢ１２中のスケ
ジュールテーブルのデータ構成を示す図である。ここで
スケジュールとは統合業務パッケージ導入計画立案の作
業に係わるスケジュールである。「フェーズ」は計画作
業を大きくフェーズというまとまりとステップという細
かい作業に分けたときのフェーズの情報である。「ステ
ップ」はフェーズ内の作業のステップの情報である。
「作業項目」は各ステップの作業項目の名称の情報であ
る。「標準日程」は各ステップの標準の日程の情報であ
る。「開始日」は各ステップの開始予定日の情報であ
る。「終了日」は各ステップの終了予定日の情報であ
る。なお標準プロジェクトＤＢ１１中のスケジュールテ
ーブルは、「フェーズ」「ステップ」「作業項目」及び
「標準日程」が設定されている。

【００２０】図５は、新プロジェクトＤＢ１２中のガイ
ドラインテーブルのデータ構成を示す図である。ガイド
ラインは統合業務パッケージ導入において前提となる大
方針である。「ガイドライン項目」はガイドラインの項
目の情報である。「内容」は各ガイドライン項目に対す
る内容の情報である。なお標準プロジェクトＤＢ１１中
のガイドラインテーブルは、「ガイドライン項目」のみ
が設定されている。

【００２１】図６は、プロジェクト発足支援モジュール
３１の処理の流れを示すフローチャートである。プロジ
ェクト発足支援モジュール３１は、標準プロジェクトＤ
Ｂ１１から体制テーブル、スケジュールテーブル及びガ
イドラインテーブルを読み込む（ステップ５１）。プロ
ジェクト発足初期画面として、表示装置４上に体制、ス
ケジュール、ガイドライン及び終了のボタンを表示する
（ステップ５２）。利用者が入力装置３のマウスを移動
し、体制ボタンをクリックすると（ステップ５３）、読
み込んだ体制テーブルを表示する（ステップ５４）。こ
の段階では「役割」を除いてテーブルの各項目は空であ
る。利用者が「氏名」欄に氏名、「部署」欄に部署名、
「内線」欄に内線番号を入力すると（ステップ５５）、
入力された情報を新プロジェクトＤＢ１２の体制テーブ
ルに保存し（ステップ５６）、プロジェクト発足初期画
面の表示（ステップ５２）に戻る。次に利用者が入力装
置３のマウスを移動し、スケジュールボタンをクリック
すると（ステップ５７）、読み込んだスケジュールテー
ブルを表示する（ステップ５８）。この段階では「開始
日」欄と「終了日」欄は空である。利用者が「標準日
程」を参考にし、「開始日」欄に実際予定の開始日と
「終了日」欄に実施予定の終了日を入力すると（ステッ
プ５９）、入力された情報を新プロジェクトＤＢ１２の
スケジュールテーブルに保存し（ステップ６０）、プロ
ジェクト発足初期画面表示（ステップ５２）に戻る。次
に利用者が入力装置３のマウスを移動し、ガイドライン
ボタンをクリックすると（ステップ６１）、読み込んだ
ガイドラインテーブルを表示する（ステップ６２）。こ
の段階では「内容」欄は空である。利用者が「内容」欄
にデータを入力すると（ステップ６３）、入力された情
報を新プロジェクトＤＢ１２のガイドラインテーブルに
保存し（ステップ６４）、プロジェクト発足初期画面表
示（ステップ５２）に戻る。この時「ガイドライン項
目」は必要に応じて追加することができる。次に利用者
が入力装置３のマウスを移動し、終了ボタンをクリック
する（ステップ６５）と、プロジェクト発足支援モジュ
ールを終了する。

【００２２】図７は、目的／目標テーブル１３のデータ
構成の例を示す図である。「目的／目標」は目的／目標
の項目の情報である。「内容」は各項目に対する内容の
情報である。

【００２３】図８は、目的／目標設定モジュール３２の
処理の流れを示すフローチャートである。目的／目標設
定モジュール３２は、目的目標設定画面として、目的と
目標の入力を促す画面を表示する（ステップ７１）。利
用者が目的に対応してその「内容」を入力し（ステップ
７２）、目標に対応してその「内容」を入力する（ステ
ップ７３）と、データ入力済みの目的／目標テーブル１
３を保存する（ステップ７４）。目的及び目標の行を必
要に応じて追加することができる。

【００２４】図９は、標準業務テーブル１４のデータ構
成を示す図である。標準業務は統合業務パッケージソフ
トがサポートしている標準の業務である。「業務名大」
は業務を大きなくくり大とその中のくくり小に２分した
ときの上位レベルの業務の識別子である。この実施例で
は大と小の２つに分けたが、大、中、小の３つやそれ以
上に分けることも可能である。「業務名小」は業務名大
の中の小さな業務単位の識別子である。「内容」は各
「業務名小」の業務の内容あるいは仕様の情報である。
「内容」によって各標準業務の詳細仕様を定義してよ
い。

【００２５】図１０は、現状業務テーブル１５のデータ
構成を示す図である。現状業務テーブル１５には現状業
務整理画面を介して入力された情報が保存される。「業
務名大」は標準業務テーブル１４の「業務名大」に該当
する情報である。現状業務整理画面で追加された場合は
その内容が反映される。「業務名小」は標準業務テーブ
ル１４の「業務名小」に該当する情報である。現状業務
整理画面で追加された場合はその内容が反映される。
「内容」は標準業務テーブル１４の「内容」に該当する
情報である。現状業務整理画面で修正あるいは追加され
た場合はその内容が反映される。「評価」は業務整理画
面の「現状評価」で選択された情報が保存される。この
実施形態では「実施」ボタンが選択された場合は「評
価」を“０”、「未実施」ボタンが選択された場合は
「評価」を“１”、「修正」ボタンが選択された場合は
「評価」を“２”、「追加」ボタンが選択された場合は
「評価」を“３”として保存している。「価値」は当該
業務の経営的な価値の情報であり、現状業務整理画面の
「価値」で入力された情報が保存される。

【００２６】図１１は、現状業務整理画面の例を示す表
示画面図である。現状業務整理画面は現状業務を整理す
るときに表示される画面である。「業務名１」は標準業
務テーブル１４の「業務名大」に該当する情報である。
「業務名２」は標準業務テーブル１４の「業務名小」に
該当する情報である。「内容」は標準業務テーブル１４
の「内容」に該当する情報である。「現状評価」は現状
の業務で実施しているか、実施していないか、実施して
いるが内容が標準業務と異なるか、あるいは統合業務パ
ッケージソフトの標準業務にはない別業務かを示すため
の情報である。「実施」ボタンは当該標準業務を現状実
施しているときに選択するためのボタンである。「未実
施」ボタンは当該標準業務を現状実施していないときに
選択するためのボタンである。「修正」ボタンは当該業
務を現状実施しているが内容が違う場合に選択するため
のボタンである。「追加」ボタンは統合業務パッケージ
ソフトの標準業務にはなく、現状実施している業務が別
業務であるときに選択するボタンである。「追加」ボタ
ンを選択すると、当該業務に関する行の下に空白の１行
が追加され、利用者は業務を追加することができる。
「価値」は当該業務の経営的な価値を示す情報である。
その業務を１件行うのに何分かかるかあるいはその業務
が１日あたり何件発生しているかなどの情報である。
「終了」ボタンは現状業務の整理が終了したときに選択
するボタンである。

【００２７】図１２は、現状業務整理支援モジュール３
３の処理の流れを示すフローチャートである。この処理
では、統合業務パッケージがサポートする標準業務を基
準として企業で実施されている現状業務の整理と区分を
行い、標準業務をそのまま実施している状態（「実
施」）か、実施していない状態（「未実施」）か、修正
した形態で実施中（「修正」）か、標準業務以外の業務
を実施中（「追加」）かについて利用者の決定がなさ
れ、その結果を現状業務テーブル１５に保存するもので
ある。

【００２８】現状業務整理支援モジュール３３は、標準
業務テーブル１４を読み込み（ステップ８１）、表示装
置４上に現状業務整理画面を表示する（ステップ８
２）。「現状評価」欄の「実施」ボタンがクリックされ
る（ステップ８３）と、当該業務を現状実施しているこ
とを示す色に変更し（ステップ８４）、その「業務名
大」「業務名小」「内容」及び「評価」を現状業務テー
ブル１５に格納する（ステップ８５）。このとき「評
価」欄には実施を示す値である０を書き込む。「現状評
価」欄の「未実施」ボタンがクリックされる（ステップ
８６）と、当該業務を現状未実施であることを示す色に
変更し（ステップ８７）、その「業務名大」「業務名
小」「内容」及び「評価」を現状業務テーブル１５に格
納する（ステップ８８）。このとき「評価」欄には未実
施を示す値である１を書き込む。「現状評価」欄の「修
正」ボタンがクリックされる（ステップ８９）と、当該
業務の内容を修正入力可能の状態にする（ステップ９
０）。利用者が入力した修正内容を受け付ける（ステッ
プ９１）と、当該業務の行について修正を示す色に変更
（ステップ９２）し、その「業務名大」「業務名小」
「内容」及び「評価」を現状業務テーブル１５に格納す
る（ステップ９３）。このとき「評価」欄には修正を示
す値である２を書き込む。「現状評価」欄の「追加」ボ
タンがクリックされる（ステップ９４）と、当該業務の
下に新規に１行の領域を追加する（ステップ９５）。利
用者の追加入力を受け付ける（ステップ９６）と、当該
業務の行についてを追加を示す色に変更し（ステップ９
７）、その「業務名大」「業務名小」「内容」及び「評
価」を現状業務テーブル１５に格納する（ステップ９
８）。このとき「評価」欄には追加を示す値である３を
書き込む。次に「価値」欄に利用者からの入力を受け付
ける（ステップ９９）と、入力された価値を現状業務テ
ーブル１５の当該業務の「価値」欄に格納する（ステッ
プ１００）。このとき未実施の業務については「価値」
欄に“−”を書き込む。この実施形態ではその業務につ
いて１件あたりの処理時間（分）と１日あたりの発生件
数（件）によって価値を示しているが、必要に応じて価
値の項目は追加可能である。最後に「終了」ボタンがク
リックされる（ステップ１０１）と、現状業務整理支援
モジュール３３の処理を終了する。

【００２９】図１３は、新業務テーブル１６のデータ構
成を示す図である。ここで新業務とは、統合業務パッケ
ージ導入後に対象となる業務という意味である。新業務
テーブル１６には図１４に示す新業務定義画面で入力さ
れた情報が保存される。「業務名大」は標準業務テーブ
ル１４の「業務名大」に該当する情報である。「業務名
小」は標準業務テーブル１４の「業務名小」に該当する
情報である。「内容」は標準業務テーブル１４の「内
容」に該当する情報である。「評価」は新業務定義画面
の「評価」で選択された情報が保存される。標準業務を
その仕様通りに「利用」する場合には「評価」に“０”
を格納し、標準業務を利用しない「未利用」の場合には
“１”を格納する。標準業務を「修正」開発した上で利
用する場合には「評価」に“２”を格納し、標準業務に
ない業務を「追加」開発する場合には「評価」に“３”
を格納する。標準業務にない追加業務の場合には、「業
務名大」「業務名小」「内容」及び「評価」の記憶欄は
新業務テーブル１６に追加されたものとなる。

【００３０】図１４は、新業務定義画面のデータ構成を
示す図である。新業務定義画面は新業務を定義するとき
に表示される画面である。「業務名１」は標準業務テー
ブル１４の「業務名大」に該当する情報である。「業務
名２」は標準業務テーブル１４の「業務名小」に該当す
る情報である。「内容」は標準業務テーブル１４の「内
容」に該当する情報である。「評価」は新業務で標準業
務を利用するか、利用しないか、利用するが内容を修正
したものか、あるいは統合業務パッケージソフトの標準
業務にはない追加業務かを示すための情報である。「利
用」ボタンは当該業務を利用するときに選択するための
ボタンである。「未利用」ボタンは当該業務を利用しな
いときに選択するためのボタンである。「修正」ボタン
は当該業務を利用するが内容が修正される場合に選択す
るためのボタンである。「追加」ボタンは統合業務パッ
ケージソフトの標準業務にはなく、新たに新業務を追加
するときに選択するボタンである。「追加」ボタンを選
択すると、当該業務の行の下に空白の１行が追加され、
利用者は業務を追加することができる。「終了」ボタン
は新業務の定義が終了したときに選択するボタンであ
る。

【００３１】図１５は、新業務定義支援モジュール３４
の処理の流れを示すフローチャートである。この処理で
は、統合業務パッケージがサポートする標準業務を利用
するに当って、標準業務をそのまま利用する（「利
用」）か、利用しない（「未利用」）か、修正した上で
利用するか（「修正」）か、標準業務以外の追加業務か
（「追加」）について利用者の決定がなされ、その結果
を新業務テーブル１６に保存するものである。決定に当
っては現状業務テーブル１５の結果が参考にされてよ
い。現状業務整理の結果として区分された「実施」「未
実施」「修正」又は「追加」業務が統合業務パッケージ
を利用するとき、「利用」「未利用」「修正」又は「追
加」業務のどの区分にするかはその企業の判断次第であ
る。例えば現状業務として「追加」業務を新業務として
やめるときには、新業務のどの区分にも入らないから入
力不要である。

【００３２】新業務定義支援モジュール３４は、標準業
務テーブル１４を読み込み（ステップ１１１）、表示装
置４上に新業務定義画面を表示する（ステップ１１
２）。「評価」欄の「利用」ボタンがクリックされると
（ステップ１１３）。当該業務の行について利用を示す
色に変更し（ステップ１１４）、その「業務名１」「業
務名２」「内容」及び「評価」を新業務テーブル１６の
該当する記憶欄に格納する（ステップ１１５）。ここで
「評価」欄には利用を示す値の０が書き込まれる。「評
価」欄の「未利用」ボタンがクリックされると（ステッ
プ１１６）、当該業務の行についてを未利用を示す色に
変更し（ステップ１１７）、その「業務名１」「業務名
２」「内容」及び「評価」を新業務テーブル１６に格納
する（ステップ１１８）。「評価」欄には未利用を示す
値の１が書き込まれる。「評価」欄の「修正」ボタンが
クリックされる（ステップ１１９）と、当該業務の内容
を修正入力可能の状態にする（ステップ１２０）。利用
者が入力した修正内容を受け付ける（ステップ１２１）
と、当該業務の行について修正を示す色に変更し（ステ
ップ１２２）、その「業務名１」「業務名２」「内容」
及び「評価」を新業務テーブル１６に格納する（ステッ
プ１２３）。このとき「評価」欄には修正を示す値であ
る２を書き込む。「評価」欄の「追加」ボタンがクリッ
クされる（ステップ１２４）と、当該業務の下に新規に
１行の領域を追加する（ステップ１２５）。利用者から
の業務定義入力を受け付ける（ステップ１２６）と、当
該業務の行について追加を示す色に変更し（ステップ１
２７）、追加された「業務名１」「業務名２」「内容」
及び「評価」を新業務テーブル１６に格納する（ステッ
プ１２８）。このとき「評価」欄には追加を示す値であ
る３を書き込む。最後に「終了」ボタンがクリックされ
る（ステップ１２９）と、新業務定義モジュール３４の
処理を終了する。

【００３３】図１６は、変化点テーブル１７のデータ構
成を示す図である。「業務名大」は標準業務テーブル１
４の「業務名大」に該当する情報である。「業務名小」
は標準業務テーブル１４の「業務名小」に該当する情報
である。「コメント」は新業務になるとどう変わるの
か、何をしなければならないのかなどの業務の変化点に
関するコメントの情報である。

【００３４】図１７は、変化点整理支援モジュール３５
の処理の流れを示すフローチャートである。ここで変化
点とは、現状業務が新業務に移行したとき何が変わるの
かを示す情報である。現状業務整理の結果として区分さ
れた「実施」「未実施」「修正」又は「追加」業務が新
業務で「利用」「未利用」「修正」又は「追加」業務の
扱いとするとき、変化点のコメントが必要か否かの判断
基準となるものを表１に示す。表１で各区分の現状業務
を各区分の新業務に移行したとき、×は業務内容に変化
がないか未利用なのでコメント入力が不要、〇はコメン
ト入力が必要、△は新業務に移るとき「修正」「追加」
の内容が同じなら入力不要、変更となるなら入力必要で
あることを示す。

【００３５】

【表１】

【００３６】変化点整理支援モジュール３５は、新業務
テーブル１６を読み込む（ステップ１３１）。次に現状
業務テーブル１５を読み込む（ステップ１３２）。そし
て新業務テーブル１６の「業務名大」「業務名小」「内
容」及び現状業務テーブル１５の「内容」を表示する
（ステップ１３３）。利用者が変化点に対する「コメン
ト」を入力する（ステップ１３４）と、「業務名大」
「業務名小」及び「コメント」を変化点テーブル１７に
格納する（ステップ１３５）。このようにして新業務に
移行するとき変更となるすべての業務について変化点の
入力と保存を行う。

【００３７】図１８は、標準価値テーブル１８のデータ
構成を示す図である。標準価値は統合業務パッケージソ
フトがサポートする標準業務によつて得られる価値に関
する情報である。「業務名大」は標準業務テーブル１４
の「業務名大」に該当する情報である。「業務名小」は
標準業務テーブル１４の「業務名小」に該当する情報で
ある。「標準価値」は統合業務パッケージソフトがサポ
ートする標準業務によって得られる価値の情報である。
例えば生産計画を１件あたり４８０分で処理するという
標準価値を示している。処理速度の他に金額やリードタ
イムなど他の価値を表す項目を設定してもよい。

【００３８】図１９は、効果算定テーブル１９のデータ
構成を示す図である。「業務名大」は標準業務テーブル
１４の「業務名大」に該当する情報である。「業務名
小」は標準業務テーブル１４の「業務名小」に該当する
情報である。「現状価値」は当該業務の現状の価値の情
報であり、現状業務テーブル１５の「価値」である。
「新価値」は当該業務が新業務に移行したときの価値の
情報である。「効果」は新業務が現状業務に比べてどの
くらい効果があるかを示す情報である。例えば生産計画
業務において年間５２５６分の短縮効果をもたらすこと
が示されている。

【００３９】図２０は、効果算定モジュール３６の処理
手順を示すフローチャートである。効果算定モジュール
３６は新業務テーブル１６を読み込む（ステップ１４
１）。次に標準価値テーブル１８を読み込む（ステップ
１４２）。次に現状業務テーブル１５を読み込む（ステ
ップ１４３）。次に新業務テーブル１６の「業務名大」
「業務名小」、「現状価値」として現状業務テーブル１
５の「価値」、「新価値」として標準価値テーブル１８
の「標準価値」をそれぞれ対応させて表示する（ステッ
プ１４４）。ここで新業務テーブル１６の「評価」が１
（未利用）の場合は「新価値」として“−”を表示す
る。また２（修正）の場合はとりあえず「標準価値」を
表示する。また３（追加）の場合は「新価値」欄を空欄
とする。次に新業務テーブル１６の「評価」が２（修
正）と３（追加）の場合は「新価値」の入力を促し、利
用者が入力した「新価値」を受け付ける（ステップ１４
５）。次に現状業務の「現状価値」と新業務の「新価
値」から各業務毎の効果を算出し表示する（ステップ１
４６）。例えば図１９に示す「業務名小」が生産計画の
「効果」は次式のようになる。 効果＝（９６０分／件−４８０分／件）×０．０３件／
日×３６５日＝５２５６分／年 ここでは１年を３６５日として計算したが、企業毎に設
定されている営業日数などで算出することも可能であ
る。ステップ１４５及び１４６をすべての新業務につい
て繰り返す。最後に入力データから効果算定テーブル１
９を作成して保存する（ステップ１４７）。

【００４０】図２１は、標準導入費用テーブル２０のデ
ータ構成を示す図である。標準導入費用は、統合業務パ
ッケージソフトがサポートしている標準の業務を導入す
る場合の標準の概算費用である。「モジュール名」は統
合業務パッケージソフトの中のモジュールの名称であ
る。モジュールによって金額が変わってくるので各モジ
ュール毎に分けてある。「ハード（サーバ）」はサーバ
として利用するハードウエアの１台あたりの標準の価格
である。「ハード（クライアント）」はクライアントと
して利用するハードウエアの１台あたりの標準の価格で
ある。「ソフト（サーバ）」はサーバにインストールさ
れるソフトウエアの１台あたりの標準の価格である。こ
の例では１台あたりという表現で示しているが、１ライ
センスあたりの価格で示すことも可能である。「ソフト
（クライアント）」はクライアントにインストールされ
るソフトウエアの１台あたりの標準の価格である。この
例では１台あたりという表現で示しているが、１ライセ
ンスあたりの価格で示すことも可能である。「導入費
用」は導入時のインストール作業などの作業費や作業支
援費などである。この例ではサーバやクライアントも含
めた１台あたりの導入費用を示している。

【００４１】図２２は、新導入費用ＤＢ２１中の標準費
用テーブルのデータ構成を示す図である。新導入に伴う
標準費用は新業務を実現する情報システムを統合業務パ
ッケージソフトがサポートしている標準業務を用いて構
築したときの概算費用を示す。各レコードの「モジュー
ル名」は統合業務パッケージソフトのモジュールの名称
であり、「業務名大」の業務分野をサポートするプログ
ラムである。「部署名」は当該モジュールを導入する部
署名である。「サーバ数」は当該モジュールを当該部署
に導入するときに設置するサーバの台数である。「クラ
イアント数」は当該モジュールを当該部署に導入すると
きに設置するクライアントの台数である。「ハード（サ
ーバ）費」は当該モジュールを当該部署に導入するとき
のサーバのハードウエア費である。「ハード（クライア
ント）費」は当該モジュールを当該部署に導入するとき
のクライアントのハードウエア費である。「ソフト（サ
ーバ）費」は当該モジュールを当該部署に導入するとき
のサーバのソフトウエア費である。「ソフト（クライア
ント）費」は当該モジュールを当該部署に導入するとき
のクライアントのソフトウエア費である。「導入工数
費」は当該モジュールを当該部署に導入するサーバおよ
びクライアントの導入工数費である。「モジュール名」
の欄の「合計」のレコードは、標準費用テーブルの各数
値項目の合計値である。

【００４２】図２３は、導入事例ＤＢ２８中の修正開発
事例テーブルのデータ構成を示す図である。修正開発事
例は別の企業又は別のプロジェクトなどで実際に修正開
発をしたときの実施事例であり、その修正内容と修正開
発費などの情報から成る。「業務名大」は標準業務テー
ブル１４の「業務名大」に該当する情報である。「業務
名小」は標準業務テーブル１４の「業務名小」に該当す
る情報である。「修正内容」は実際に行われた修正開発
における修正内容例の情報である。「修正開発費用」は
実際に行われた修正開発において発生した修正開発費用
例の情報である。

【００４３】図２４は、新導入費用ＤＢ２１中の修正開
発費テーブルのデータ構成を示す図である。新導入に伴
う修正開発費は、サポートされる標準業務の標準費用に
対して追加される修正開発費の情報である。「業務名
大」は標準業務テーブル１４の「業務名大」に該当する
情報である。「業務名小」は標準業務テーブル１４の
「業務名小」に該当する情報である。「修正内容」は修
正開発の内容を示す情報であり、新業務テーブル１６の
「内容」に該当する。「修正開発費用」は、追加される
修正開発費用の概算見積値である。

【００４４】図２５は、導入事例ＤＢ２８中の追加開発
事例テーブルのデータ構成を示す図である。追加開発事
例は別の企業又は別のプロジェクトなどで実際に追加開
発をしたときの実施事例であり、その追加内容と追加開
発費などの情報から成る。「業務名大」は標準業務テー
ブル１４の「業務名大」に相当する情報であり、追加開
発の業務名が入る。「業務名小」は標準業務テーブル１
４の「業務名小」に相当する情報であり、追加開発の業
務名が入る。「追加内容」は実際に行われた追加開発に
おける追加内容例の情報である。「追加開発費用」は実
際に行われた追加開発において発生した追加開発費用例
の情報である。

【００４５】図２６は、新導入費用ＤＢ２１中の新追加
開発費テーブルのデータ構成を示す図である。新導入に
伴う追加開発費は標準業務外の追加業務の追加開発費の
情報である。「業務名大」は標準業務テーブル１４の
「業務名大」に相当する情報であり、新業務テーブル１
６の「業務名大」に該当する。「業務名小」は標準業務
テーブル１４の「業務名小」に相当する情報であり、新
業務テーブル１６の「業務名小」に該当する。「追加内
容」は追加開発の内容を示す情報であり、新業務テーブ
ル１６の「内容」に該当する。「追加開発費用」は新業
務の追加開発において発生する追加開発費用の概算見積
値である。

【００４６】図２７は、新導入費用ＤＢ２１中の導入費
合計テーブルのデータ構成を示す図である。導入費合計
は統合パッケージソフトを用いた新業務の情報システム
を構築するときに発生する費用の合計の概算見積値であ
る。「標準合計」は統合パッケージソフトがサポートす
る標準モジュールの導入に発生する費用を示し、標準費
用テーブルの合計欄の数値である。「修正合計」は統合
業務パッケージを用いた新業務の情報システム構築にお
いて統合パッケージソフトが提供するモジュールを修正
開発する部分で発生する追加費用であり、修正開発費テ
ーブルの「修正開発費用」の合計である。「追加合計」
は統合パッケージソフトが提供するモジュールとは別に
追加業務の開発で発生する費用であり、追加開発費テー
ブルの「追加開発費用」の合計である。「総合計」は、
「標準合計」「修正合計」「追加合計」の費用を総合計
した情報である。

【００４７】図２８は、導入費用見積支援モジュール３
７の処理の流れを示すフローチャートである。導入費用
見積支援モジュール３７は、新業務テーブル１６を読み
込む（ステップ１５１）。次に標準導入費用テーブル２
０を読み込む（ステップ１５２）。利用者によって導入
する「モジュール名」、設置する「部署名」、設置する
サーバ台数及びクライアント台数が入力されると（ステ
ップ１５３）、標準導入費用テーブルに基づきハード費
用、ソフト費用および導入工数費を算出し（ステップ１
５４）、算出した標準費用を表示する（ステップ１５
５）。また標準費用テーブルを作成して新導入費用ＤＢ
２１に保存する（ステップ１５６）。このとき各列の合
計を合計レコードとして標準費用テーブルの最後のレコ
ードとして書き込む。

【００４８】次に標準業務テーブル１４と導入事例ＤＢ
２８から修正開発事例テーブルを読み込み（ステップ１
５７）、新業務テーブル１６の「評価」が２（修正）の
業務について「業務名大」と「業務名小」、標準業務テ
ーブル１４の「内容」、修正開発事例テーブルの「修正
内容」と「修正開発費用」、新業務テーブル１６の「内
容」を対応させて表示する（ステップ１５８）。利用者
が標準の「内容」と事例の「修正内容」と新業務の「内
容」を比較判断し、事例の「修正開発費用」を参考に新
業務の修正開発費を入力すると（ステップ１５９）、修
正開発費テーブルを作成して新導入費用ＤＢ２１に保存
する（ステップ１６０）。

【００４９】次に導入事例ＤＢ２８から追加開発事例テ
ーブルを読み込み（ステップ１６１）、新業務テーブル
１６の「評価」が３（追加）の業務について「業務名
大」と「業務名小」、追加開発事例テーブルの「追加内
容」と「追加開発費用」、新業務テーブル１６の「内
容」を対応させて表示する（ステップ１６２）。ここで
新業務の追加開発業務に該当する追加開発事例の「業務
名大」「業務名小」がなければ、「業務名大」が同一の
ものを参考として表示する。利用者が事例の「追加内
容」と新業務の「内容」を比較判断し、事例の「追加開
発費用」を参考に新業務の追加開発費を入力すると（ス
テップ１６３）、追加開発費テーブルを作成して新導入
費用ＤＢ２１に保存する（ステップ１６４）。

【００５０】次に標準費用テーブルの「合計」と、修正
開発費テーブルの修正開発費合計と、追加開発費テーブ
ルの追加開発費合計とから導入費用の総合計を計算し
（ステップ１６５）、標準合計、修正合計、追加合計及
び総合計を表示し（ステップ１６６）、導入費合計テー
ブルを作成して新導入費用ＤＢ２１に保存する（ステッ
プ１６７）。

【００５１】図２９は、標準後続プロジェクトＤＢ２２
の日程テーブルのデータ構成を示す図である。後続プロ
ジェクトとは、統合業務パッケージ導入に伴って開始さ
れる開発プロジェクトを言い、導入計画立案に続くプロ
ジェクトを意味する。標準後続プロジェクト日程は統合
業務パッケージソフトのサポートする標準業務で導入を
行った場合の標準の日程の情報である。「開発フェー
ズ」は標準の導入における開発フェーズの名称である。
「期間」は当該開発フェーズに必要な標準の期間であ
る。

【００５２】図３０は、標準後続プロジェクトＤＢ２２
の体制テーブルのデータ構成を示す図である。標準後続
プロジェクト体制は統合パッケージソフトのサポートす
る標準業務で導入を行った場合の標準の体制の情報であ
る。「開発フェーズ」は標準業務の導入における開発フ
ェーズの名称である。「マネージャー」は当該フェーズ
における標準の必要マネージャー数である。「リーダ
ー」は当該フェーズにおける標準の必要リーダー数であ
る。「メンバー」は当該フェーズにおける標準の必要メ
ンバー数である。「事務局」は当該フェーズにおける標
準の事務局の人数である。この例では１モジュールにお
ける開発体制を示す。複数モジュールを開発する場合
は、例えば生産と会計の２モジュールを開発する場合な
どは単純に必要数を２倍するなどして求めればよい。あ
るいは２モジュール、３モジュール開発の場合に分けて
標準後続プロジェクトの体制テーブルを作成しておくこ
とも可能である。

【００５３】図３１は、導入事例ＤＢ２８中の修正後続
プロジェクト日程テーブルのデータ構成を示す図であ
る。修正後続プロジェクト日程は統合パッケージソフト
の提供するモジュールを修正開発する場合の平均的な日
程の情報である。「開発フェーズ」は修正開発における
開発フェーズの名称である。「期間」は当該開発フェー
ズに必要な平均的な期間である。

【００５４】図３２は、導入事例ＤＢ２８中の修正後続
プロジェクト体制テーブルのデータ構成を示す図であ
る。修正後続プロジェクト体制は統合パッケージソフト
の提供するモジュールを修正開発する場合の平均的な体
制の情報である。「開発フェーズ」は修正開発における
開発フェーズの名称である。「業務名小の数１から５」
は修正開発する「業務名小」の数が１から５の場合の必
要人員の平均的な値である。「業務名小の数６から１
０」は修正開発する「業務名小」の数が６から１０の場
合の必要人員の平均的な値である。「業務名小の数１１
から１５」は修正開発する「業務名小」の数が１１から
１５の場合の必要人員の平均的な値である。「業務名小
の数１６から２０」は修正開発する「業務名小」の数が
１６から２０の場合の必要人員の平均的な値である。
「業務名小の数２１から２５」は修正開発する「業務名
小」の数が２１から２５の場合の必要人員の平均的な値
である。この例では業務名小の数が１から２５までを例
として示しているが、それ以上についても同様に修正後
続プロジェクト体制テーブルを拡張できる。

【００５５】図３３は、導入事例ＤＢ２８中の追加後続
プロジェクト日程テーブルのデータ構成を示す図であ
る。追加後続プロジェクト日程は、統合パッケージソフ
トが提供するモジュールとは別のプログラムを追加開発
する場合の平均的な日程の情報である。「開発フェー
ズ」は追加開発における開発フェーズの名称である。
「期間」は当該開発フェーズに必要な平均的な期間であ
る。

【００５６】図３４は、導入事例ＤＢ２８中の追加後続
プロジェクト体制テーブルのデータ構成を示す図であ
る。追加後続プロジェクト体制は統合パッケージソフト
が提供するモジュールとは別のプログラムを追加開発す
る場合の平均的な体制の情報である。「開発フェーズ」
は追加開発における開発フェーズの名称の情報である。
「業務名小の数１から５」は追加開発する「業務名小」
の数が１から５の場合の必要人員の平均的な値である。
「業務名小の数６から１０」は追加開発する「業務名
小」の数が６から１０の場合の必要人員の平均的な値で
ある。「業務名小の数１１から１５」は追加開発する
「業務名小」の数が１１から１５の場合の必要人員の平
均的な値である。「業務名小の数１６から２０」は追加
開発する「業務名小」の数が１６から２０の場合の必要
人員の平均的な値である。「業務名小の数２１から２
５」は追加開発する「業務名小」の数が２１から２５の
場合の必要人員の平均的な値である。この例では業務名
小の数が１から２５までを例として示しているが、それ
以上についても同様に追加後続プロジェクト体制テーブ
ルを拡張できる。

【００５７】図３５ａ及び図３５ｂは、新後続プロジェ
クトＤＢ２３の体制テーブルのデータ構成を示す図であ
る。新後続プロジェクト体制は、統合業務パッケージソ
フトを用いた新業務を実現する情報システムの構築にお
いて標準業務、修正開発業務、追加開発業務の全てを含
んだ構築体制の情報である。「モジュール名大」は後続
プロジェクトが開発するモジュールの名称であり、大き
なくくりの名称である。この例では後続プロジェクトが
開発する情報システム全体を示すくくりを全体、その次
のレベルとして生産という大きなモジュールのくくりを
示している。大きなモジュールは標準業務テーブル１４
の「業務名大」に該当する名称と考えてよい。「標準／
修正／追加」は当該モジュールにおける標準導入、修正
開発、追加開発によるチーム区分の情報である。「開発
フェーズ」は当該モジュール、当該チーム区分に関する
開発フェーズであり、標準後続プロジェクトＤＢ２２の
日程テーブルの「開発フェーズ」に相当する。「役割」
は当該チーム内での役割を示す情報である。「氏名」は
当該チームに参加するメンバの氏名の情報である。この
例では、木村一郎は全体のマネージャーとして参加して
いる。本橋次郎は生産モジュールにおける標準導入チー
ムのリーダーとして参加している。佐々木三郎は生産モ
ジュールの標準導入チームのメンバーとして参加してい
る。

【００５８】図３６は、新後続プロジェクトＤＢ２３の
日程テーブルのデータ構成を示す図である。新後続プロ
ジェクト日程は統合パッケージソフトを用いた新業務を
実現する情報システムの構築において標準業務、修正開
発業務、追加開発業務の全てを含んだ日程の情報であ
る。「モジュール名大」は後続プロジェクトが開発する
モジュールの名称であり、新後続プロジェクトＤＢ２３
の体制テーブルの「モジュール名大」に該当する名称で
ある。「標準／修正／追加」は当該モジュールにおける
標準導入、修正開発、追加開発によるチーム区分の情報
である。「開発フェーズ」は後続プロジェクトの開発フ
ェーズの名称である。「開始日」は当該開発フェーズの
開始予定日である。「終了日」は当該開発フェーズの終
了予定日である。

【００５９】図３７は、後続プロジェクト計画モジュー
ル３８の処理の流れを示すフローチャートである。後続
プロジェクト計画モジュール３８は、新業務テーブル１
６を読み込み（ステップ１７１）、標準後続プロジェク
トＤＢ２２の日程テーブルと体制テーブルを読み込み
（ステップ１７２）、導入事例ＤＢ２８から修正後続プ
ロジェクト日程テーブルと修正後続プロジェクト体制テ
ーブル並びに追加後続プロジェクト日程テーブルと追加
後続プロジェクト体制テーブルとを読み込む（ステップ
１７３）。標準後続プロジェクトＤＢ２２の体制テーブ
ルから読み込んだ人員数を標準導入体制と呼ぶ。次に新
業務テーブル１６の「評価」から修正する「業務名小」
の数を求め、修正後続プロジェクト体制テーブルを参照
してその「業務名小」の数に一致する後続プロジェクト
に必要な人員数を求める（ステップ１７４）。これを修
正開発体制と呼ぶ。また新業務テーブル１６の「評価」
から追加する「業務名小」の数を求め、追加後続プロジ
ェクト体制テーブルを参照してその「業務名小」の数に
一致する後続プロジェクトに必要な人員数を求める（ス
テップ１７５）。これを追加開発体制と呼ぶ。そして後
続プロジェクトに必要な標準導入体制、修正開発体制及
び追加開発体制を表示装置４上に表示する（ステップ１
７６）。利用者が開発体制の人員数に対し担当者氏名を
割り当てて入力する（ステップ１７７）と、後続プロジ
ェクト体制テーブルを作成して新後続プロジェクトＤＢ
２３に保存する（ステップ１７８）。次に利用者が後続
プロジェクトの開始日を入力する（ステップ１７９）
と、標準後続プロジェクトＤＢ２２の日程テーブルを参
照して各開発フェーズの「期間」からその開始日と終了
日を計算し、また修正後続プロジェクト日程テーブルを
参照して各開発フェーズの「期間」からその開始日と終
了日を計算し、また追加後続プロジェクト日程テーブル
を参照して各開発フェーズの「期間」からその開始日と
終了日を計算する（ステップ１８０）。いずれも最初の
開発フェーズの開始日を入力された開始日とし、以後
「期間」の日数を加算して後続の開発フェーズの開始日
を求める。各開発フェーズの終了日は直続する開発フェ
ーズの１日前の日とする。次に後続プロジェクト日程テ
ーブルを作成して新後続プロジェクトＤＢ２３に保存し
（ステップ１８１）、後続プロジェクトの開発日程を表
示する（ステップ１８２）。利用者が表示されている日
程に対し変更入力をする（ステップ１８３）と、後続プ
ロジェクト日程テーブルを更新する（ステップ１８
４）。この実施形態では生産モジュールの後続プロジェ
クトについて示したが、同様の方法で他モジュールにつ
いても後続プロジェクトの計画を作成することができ
る。

【００６０】図３８は、標準計画書テーブル２４のデー
タ構成を示す図である。標準計画書テーブル２４は計画
書に記載する標準の項目とその項目に該当する導入計画
で検討した検討結果のデータが保存してあるテーブル名
称の情報を含む。「項目」は計画書に記載する標準の項
目の名称である。「該当データ」は当該項目に対応する
データが保存してあるテーブルの名称である。「項目」
が表紙、目次及び始めにに対応する「該当データ」はな
い。

【００６１】図３９は、新計画書ＤＢ２５中の項目採否
テーブルのデータ構成を示す図である。「項目」は標準
計画書の標準項目の名称である。「採否」は当該項目を
今回作成する計画書に記載するか否かの情報である。
「順序」は採用された記載項目の計画書の中での順序を
示す情報である。

【００６２】図４０は、新計画書ＤＢ２５の内容テーブ
ルのデータ構成を示す図である。新計画書の内容テーブ
ルは計画書に記載する項目であるが、導入計画の中でデ
ータとして保存していない項目についての内容の情報で
ある。「項目」は計画書に記載するがデータがない項目
の名称である。「内容」は当該項目の内容の情報であ
る。

【００６３】図４１は、計画書作成支援モジュール３９
の処理の流れを示すフローチャートである。計画書作成
支援モジュール３９は標準計画書テーブル２４を読み込
み（ステップ１９１）、その「項目」を表示装置４上に
表示する（ステップ１９２）。利用者が各項目を計画書
に盛り込むか否かおよび計画書での順序を入力する（ス
テップ１９３）と、項目採否テーブルを作成して新計画
書ＤＢ２５に保存する（ステップ１９４）。

【００６４】次に標準計画書テーブル２５の「該当デー
タ」がなしの項目について内容入力画面を表示する（ス
テップ１９５）。利用者が「内容」を入力する（ステッ
プ１９６）と、内容テーブルを作成して新計画書ＤＢ２
５に保存する（ステップ１９７）。

【００６５】次に計画書に盛り込む項目を標準計画書テ
ーブル２４の「該当データ」から採用する各「項目」に
該当するテーブルを読み込む（ステップ１９８）。ここ
で「該当データ」が“なし”の項目については新計画書
ＤＢ２５の内容テーブルから読み込む。各項目の採否と
採用項目の順序は標準計画書テーブル２５の項目採否テ
ーブルから取得する。次に読み込んだデータから印刷イ
メージを作成する（ステップ１９９）。次に項目採否テ
ーブルの「順序」に基づき印刷イメージを順に表示装置
４上に表示する（ステップ２００）。利用者が順序の変
更あるいは内容テーブルの「内容」の変更を入力する
（ステップ２０１）と、該当する項目採否テーブルある
いは新計画書ＤＢ２５の内容テーブルを書き換える（ス
テップ２０２）。ここで変更されるごとにステップ１９
８に戻りデータの読み込みと印刷イメージの作成と表示
が繰り返され、計画書の編集作業を行うことができる。
次に利用者が印刷ボタンをクリックすると表示している
印刷イメージを記憶装置２上に保存し（ステップ２０
３）、印刷イメージを印刷装置５の用紙上に印刷する
（ステップ２０４）。

【００６６】この実施形態では標準計画書の中から「項
目」を選択する場合のみを示したが、標準計画書にない
項目を計画書に盛り込みたい場合などは、項目を追加
し、その項目に該当するデータを指定することで標準に
ない項目を計画書に入れるなどの方法をとることもでき
る。また同様に計画作業の成果として保存していないデ
ータについても計画書に盛り込みたい項目を追加し、そ
の項目に該当するデータの保存場所を指定することによ
ってそのデータを計画書に入れることもできる。

【００６７】図４２は、標準プロジェクトＤＢ１１の標
準生産物テーブルのデータ構成を示す図である。「作業
項目」は作業項目の名称である。「生産物」は当該作業
項目で検討した結果作成されるテーブルの名称である。

【００６８】図４３ａおよび図４３ｂは、進捗管理テー
ブル２６のデータ構成を示す図である。「日付」は進捗
管理を実施した日付を示す情報である。「テーブル名」
は進捗管理でチェックしたテーブル名である。「成果」
は進捗管理でチェックした結果のテーブルの有無であ
る。この例では存在した場合を○、存在しない場合を×
で示す。

【００６９】図４４は、進捗管理モジュール４０の処理
手順を示すフローチャートである。進捗管理モジュール
４０は新プロジェクトＤＢ１２からスケジュールテーブ
ルを読み込む（ステップ２１１）。次に標準プロジェク
トＤＢ１１の標準生産物テーブルを読み込む（ステップ
２１２）。スケジュールテーブルの「作業項目」に対応
するテーブルを標準生産物テーブルから検索し該当する
テーブルにアクセスする（ステップ２１３）。ＤＢＭＳ
（データベースマネジメントシステム）からの応答メッ
セージを基に該当テーブルの存在を判断する（ステップ
２１４）。現在販売されているＤＢＭＳはテーブルが存
在しなければテーブルがないというエラーメッセージを
返すので、このエラーメッセージを受信するか否かによ
ってテーブルの存在が判断できる。次にその結果を進捗
管理テーブル２６に保存する（ステップ２１５）。また
進捗確認結果を表示装置４上に表示する（ステップ２１
６）。表示方法としては、作業項目とそれに対応するテ
ーブルの存在を成果として示すだけの簡単なものや作業
項目と日付のマトリクス表を作成し、日付に対して作業
項目に該当するテーブルがあったものだけに○を表示す
るなどの様々の表示方法が考えられる。進捗管理テーブ
ル２６によつて導入計画の立案が新プロジェクトＤＢ１
２に設定したスケジュール通りに進行しているか否かを
判定できる。すなわち指定されたテーブルが存在すると
いうことはそのテーブルについての作業が開始されたこ
とを示す。次のテーブルが存在するということは前のス
テップが終了したことを示す。

【００７０】図４５は、下流ＣＡＳＥから下流ＣＡＳＥ
連動モジュール４１へ送られる問い合わせ２２１のデー
タ構成を示す図である。「テーブル名」は問い合せ対象
のテーブル名である。「問い合わせ項目」は問い合わせ
対象テーブルの対象項目の情報である。「キー項目」は
問い合わせ対象テーブルで対象レコードを決定するため
のキーとなる項目の名称である。「キー」はキー項目の
値である。この例では新業務テーブル１６の「業務名
小」が作業指示であるレコードについてその評価の値が
何かを問い合わせるための問い合わせメッセージであ
る。

【００７１】図４６は、下流ＣＡＳＥ連動モジュール４
１から下流ＣＡＳＥへ送られる回答２２２のデータ構成
を示す図である。回答２２２は問い合わせ２２１に対す
る回答である。「問い合わせ項目」は問い合わせ２２１
の「問い合わせ項目」に該当する情報である。「値」は
当該問い合わせ項目に対する値である。この例では問い
合わせ２２１に対して新業務テーブル１６の「業務名
小」が作業指示であるレコードを検索した結果、その
「値」が０であったことを回答するメッセージである。

【００７２】図４７は、下流ＣＡＳＥ連動モジュール４
１の処理の流れを示すフローチャートである。統合業務
パツケージのモジュールを利用したり同モジュールに修
正、追加を施す代わりに業務によりＣＡＳＥツールを使
用することが可能である。下流ＣＡＳＥ連動モジュール
４１は、ＣＡＳＥツールにデータベースのデータを提供
するプログラムである。下流ＣＡＳＥ連動モジュール４
１は、下流ＣＡＳＥツールからの問い合わせ２２１を受
信する（ステップ２３１）と、「テーブル名」で指定さ
れたテーブルを検索しデータを読み込む（ステップ２３
２）。この例の問い合わせ２２１は新業務テーブル１６
の「業務名小」が作業指示について評価の問い合わせで
あるので、新業務テーブル１６にアクセスし、「業務名
小」が作業指示であるレコードを検索し、該当レコード
の「評価」の値を読み込む。次に読み込んだ結果を回答
２２２としてＣＡＳＥツールへ送信する（ステップ２３
３）。

【００７３】図４８は、作業手順案内テーブル２７のの
データ構成を示す図である。「項目名」は案内の対象と
する作業項目の名称である。「ファイル名」は当該作業
項目に関する作業手順案内プログラムを格納するファイ
ルの名称である。作業手順案内プログラムは、導入計画
に伴う作業項目、作業の手順などを紹介し、説明するプ
ログラムであり、作業内容、作業手順に不案内な利用者
によって利用されるプログラムである。なお「項目名」
に（文字）とあるのは、そのプログラムが表示用のテキ
スト情報を含むことを意味する。（映像）とあるのは、
そのプログラムが表示用の画像情報を含むことを意味す
る。

【００７４】図４９は、作業手順案内モジュール４２の
処理の流れを示すフローチャートである。作業手順案内
モジュール４２は、作業手順案内テーブル２７を読み込
み（ステップ２４１）、その「項目名」をメニューとし
て表示する（ステップ２４２）。利用者がメニューから
いずれかの項目名を選択する（ステップ２４３）と、作
業手順案内テーブル２７を参照し、対応する「ファイル
名」の付けられた該当プログラムを起動する（ステップ
２４４）。該当プログラムがテキスト情報を含んでおれ
ばそのテキスト情報を表示装置４上に表示する。映像情
報を含んでおればその映像情報を表示する。このときテ
キスト情報であれば一般の文書ソフトウェアの形式での
提供も可能である。また映像なども一般の映像ソフトの
形式での提供も可能である。一般のソフトウェアの形式
に合わせてあれば、本発明のシステムは文書や映像のコ
ンテンツだけをデータとして保存し、それを利用者に見
せるために一般のソフトを起動するような方法をとるこ
とができる。

【００７５】図５０は、マルチ拠点連動モジュール４３
の処理の流れを示すフローチャートである。ここで拠点
とはクライアント８を指す。それぞれ別々の拠点にいる
複数の利用者がグループとなつて同一の作業を進めると
きに同一の表示画面を共用するためにマルチ拠点連動モ
ジュール４３が利用される。例えば拠点Ａと拠点Ｂのク
ライアント８がともに新業務定義支援モジュール３４を
使用し、同一の新業務定義画面を各々の表示装置４上に
表示するものとする。拠点Ａのクライアント８である業
務について「利用」ボタンが押下されたとすると、マル
チ拠点連動モジュール４３がこの入力操作を検出し、新
業務定義支援モジュール３４に入力データを渡すととも
に拠点Ｂのクライアント８のマルチ拠点連動モジュール
４３へこの入力操作を通知する。拠点Ａの新業務定義支
援モジュール３４はこの入力データを受けてその表示装
置４上の利用色を変更する。拠点Ｂのマルチ拠点連動モ
ジュール４３は、この入力データを受け取り、拠点Ｂの
新業務定義支援モジュール３４に渡すと、同新業務定義
支援モジュール３４はその表示装置４上の利用色を変更
する。同様に拠点Ｂの入力操作は、マルチ拠点連動モジ
ュール４３を介して拠点Ａの新業務定義支援モジュール
３４に伝えられ、拠点Ａの新業務定義支援モジュール３
４が拠点Ｂの新業務定義支援モジュール３４と同じ処理
を行う。このようにして拠点Ａと拠点Ｂのクライアント
８は同一の表示画面を共用する。

【００７６】利用者がそのクライアント８の入力装置３
を介して指令又はデータを入力すると、マルチ拠点連動
モジュール４３がこの入力操作を検出し（ステップ２５
１）、その入力データを自クライアントの実行中のモジ
ュールへ引き渡す（ステップ２５２）。また同一データ
を連動すべき別拠点のクライアントへ送信する（ステッ
プ２５３）。図示の例では拠点Ａの利用者からデータ入
力があったので拠点Ｂへ送信する。逆に拠点Ｂでデータ
入力があれば拠点Ａへ送信することとなる。次に拠点Ｂ
のマルチ拠点連動モジュール４３は、送信されたデータ
を受信し（ステップ２５４）、拠点Ｂで動作している同
一の該当モジュールへデータを引き渡す（ステップ２５
５）。利用者が何かの入力操作をするごとにマルチ拠点
連動モジュール４３は、他拠点のマルチ拠点連動モジュ
ール４３へデータの送信を行う。この処理により複数拠
点が同一の表示画面を共用し該当モジュールの連動が可
能となる。

【００７７】図５１は、アップデートモジュール４４の
処理の流れを示すフローチャートである。アップデート
モジュール４４は、通信モジュール４５を経由して統合
業務パッケージソフトのベンダの提供するサーバ１００
と接続する（ステップ２６１）。ベンダ側のサーバ１０
０は、この接続に対しユーザＩＤとパスワードを要求す
る（ステップ２６２）。利用者側クライアント８は、ユ
ーザＩＤとパスワードの入力を催促する画面を表示する
（ステップ２６３）。利用者がユーザＩＤとパスワード
を入力する（ステップ２６４）と、利用者側クライアン
ト８は、ユーザＩＤとパスワードをベンダ側のサーバ１
００へ送信する（ステップ２６５）。ベンダ側のサーバ
１００は、ユーザＩＤとパスワードに誤りがないことを
確認し（ステップ２６６）、アップデート可能なテーブ
ルのメニューを送信する（ステップ２６７）。例えば導
入事例ＤＢ２８の最新版、標準業務テーブル１４、標準
価値テーブル１８の最新版などのテーブルが対象とな
る。利用者側クライアント８は、メニューを受信し表示
する（ステップ２６８）。利用者がメニューからいずれ
かの項目を選択する（ステップ２６９）と、選択された
項目をベンダ側のサーバ１００へ送信する（ステップ２
７０）。ベンダ側のサーバ１００は、選択された項目を
受信し（ステップ２７１）、該当するテーブルなどのデ
ータをデータベースから読み込む（ステップ２７２）。
そして読み込んだデータを送信する（ステップ２７
３）。利用者側クライアント８は、このデータを受信し
（ステップ２７４）、該当するデータベースに保存する
（ステップ２７５）。この事例ではベンダ側のサーバ１
００からのデータのダウンロードについて示したが、利
用者側クライアント８からのデータのアップロードも可
能である。このアップデートモジュールにより導入事例
のアップデートや標準業務テーブルのアップデートなど
をネットワーク９０を介して遠隔地から行うことができ
る。

【００７８】

【発明の効果】以上説明したように本発明によれば、統
合業務パッケージソフトを利用して情報システムを構築
する際に、このパッケージソフトの導入計画を立案する
段階で新業務ごとに標準利用、修正開発及び追加開発の
いずれかの区分に明確に切り分けるので、以後この区分
を基にして導入概算費用の見積り、後続する開発プロジ
ェクトの計画立案を行うことができ、後の設計フェーズ
でアドオン部分を再検討するための工数が減少し、短期
間で統合業務パッケージソフトの導入を立ち上げること
ができる。

【図面の簡単な説明】

【図１】実施形態のシステム構成図である。

【図２】実行されるプログラム・モジュールをクローズ
アップする図１のシステム構成図である。

【図３】実施形態の新プロジェクトＤＢ１２中の体制テ
ーブルのデータ構成図である。

【図４】実施形態の新プロジェクトＤＢ１２中のスケジ
ュールテーブルのデータ構成図である。

【図５】実施形態の新プロジェクトＤＢ１２中のガイド
ラインテーブルのデータ構成図である。

【図６】実施形態のプロジェクト発足支援モジュール３
１の処理の流れを示すフローチャートである。

【図７】実施形態の目的／目標テーブル１３のデータ構
成図である。

【図８】実施形態の目的／目標設定モジュール３２の処
理の流れを示すフローチャートである。

【図９】実施形態の標準業務テーブル１４のデータ構成
図である。

【図１０】実施形態の現状業務テーブル１５のデータ構
成図である。

【図１１】現状業務整理画面の例を示す図である。

【図１２】実施形態の現状業務整理支援モジュール３３
の処理の流れを示すフローチャートである。

【図１３】実施形態の新業務テーブル１６のデータ構成
図である。

【図１４】新業務定義画面の例を示す図である。

【図１５】実施形態の新業務定義支援モジュール３４の
処理の流れを示すフローチャートである。

【図１６】実施形態の変化点テーブル１７のデータ構成
図である。

【図１７】実施形態の変化点整理支援モジュール３５の
処理の流れを示すフローチャートである。

【図１８】実施形態の標準価値テーブル１８のデータ構
成図である。

【図１９】実施形態の効果算定テーブル１９のデータ構
成図である。

【図２０】実施形態の効果算定モジュール３６の処理手
順を示すフローチャートである。

【図２１】実施形態の標準導入費用テーブル２０のデー
タ構成図である。

【図２２】実施形態の新導入費用ＤＢ２１中の標準費用
テーブルのデータ構成図である。

【図２３】実施形態の導入事例ＤＢ２８中の修正開発事
例テーブルのデータ構成を示す図である。

【図２４】実施形態の新導入費用ＤＢ２１中の修正開発
費テーブルのデータ構成を示す図である。

【図２５】実施形態の導入事例ＤＢ２８中の追加開発事
例テーブルのデータ構成を示す図である。

【図２６】実施形態の新導入費用ＤＢ２１中の追加開発
費テーブルのデータ構成を示す図である。

【図２７】実施形態の新導入費用ＤＢ２１中の導入費合
計テーブルのデータ構成を示す図である。

【図２８】実施形態の導入費用見積支援モジュール３７
の処理の流れを示すフローチャートである。

【図２９】実施形態の標準後続プロジェクトＤＢ２２の
日程テーブルのデータ構成を示す図である。

【図３０】実施形態の標準後続プロジェクトＤＢ２２の
体制テーブルのデータ構成を示す図である。

【図３１】実施形態の導入事例ＤＢ２８中の修正後続プ
ロジェクト日程テーブルのデータ構成を示す図である。

【図３２】実施形態の導入事例ＤＢ２８中の修正後続プ
ロジェクト体制テーブルのデータ構成を示す図である。

【図３３】実施形態の導入事例ＤＢ２８中の追加後続プ
ロジェクト日程テーブルのデータ構成を示す図である。

【図３４】実施形態の導入事例ＤＢ２８中の追加後続プ
ロジェクト体制テーブルのデータ構成を示す図である。

【図３５ａ】実施形態の新後続プロジェクトＤＢ２３の
体制テーブルのデータ構成を示す図である。

【図３５ｂ】実施形態の新後続プロジェクトＤＢ２３の
体制テーブル（続き）のデータ構成を示す図である。

【図３６】実施形態の新後続プロジェクトＤＢ２３の日
程テーブルのデータ構成を示す図である。

【図３７】実施形態の後続プロジェクト計画モジュール
３８の処理の流れを示すフローチャートである。

【図３８】実施形態の標準計画書テーブル２４のデータ
構成を示す図である。

【図３９】実施形態の新計画書ＤＢ２５中の項目採否テ
ーブルのデータ構成を示す図である。

【図４０】実施形態の新計画書ＤＢ２５中の内容テーブ
ルのデータ構成を示す図である。

【図４１】実施形態の計画書作成支援モジュール３９の
処理の流れを示すフローチャートである。

【図４２】実施形態の標準プロジェクトＤＢ１１の標準
生産物テーブルのデータ構成を示す図である。

【図４３ａ】実施形態の進捗管理テーブル２６のデータ
構成を示す図である。

【図４３ｂ】実施形態の進捗管理テーブル２６（続き）
のデータ構成を示す図である。

【図４４】実施形態の進捗管理モジュール４０の処理手
順を示すフローチャートである。

【図４５】実施形態の下流ＣＡＳＥから下流ＣＡＳＥ連
動モジュール４１へ送られる問い合わせ２２１のデータ
構成を示す図である。

【図４６】実施形態の下流ＣＡＳＥ連動モジュール４１
から下流ＣＡＳＥへ送られる回答２２２のデータ構成を
示す図である。

【図４７】実施形態の下流ＣＡＳＥ連動モジュール４１
の処理の流れを示すフローチャートである。

【図４８】実施形態の作業手順案内テーブル２７のデー
タ構成を示す図である。

【図４９】実施形態の作業手順案内モジュール４２の処
理の流れを示すフローチャートである。

【図５０】実施形態のマルチ拠点連動モジュール４３の
処理の流れを示すフローチャートである。

【図５１】実施形態のアップデートモジュール４４の処
理の流れを示すフローチャートである。

【符号の説明】

１４：標準業務テーブル、１５：現状業務テーブル、１
６：新業務テーブル、２０：標準導入費用テーブル、２
１：新導入費用データベース、２２：標準後続プロジェ
クトデータベース、２３：新後続プロジェクトデータベ
ース、３３：現状業務整理支援モジュール、３４：新業
務定義支援モジュール、３７：導入費用見積支援モジュ
ール、３８：後続プロジェクト計画モジュール

Claims (5)

【特許請求の範囲】
1. 【請求項１】統合業務パッケージソフトの導入計画立案
   を支援するシステムであって、統合業務パッケージソフ
   トが提供する標準業務の仕様を格納する標準業務テーブ
   ル手段と、該標準業務テーブルを表示装置上に表示し、
   各業務について標準業務の仕様通りに標準業務を利用す
   るか、標準業務を利用しないか、標準業務の仕様を修正
   開発した上で利用するか、標準業務以外の仕様の業務を
   追加開発するのかの区分が入力されたとき、業務の識別
   子に対応する該区分を新業務テーブルとして記憶装置に
   保存する処理手段とを有することを特徴とする統合業務
   パッケージソフト導入計画立案支援システム。
2. 【請求項２】コンピュータ読み取り可能なプログラムを
   格納する記憶媒体において、該プログラムは統合業務パ
   ッケージソフトの導入計画立案を支援するプログラムで
   あって、下記機能を含むプログラムであることを特徴と
   するプログラムの記憶媒体： （ａ）統合業務パッケージソフトが提供する標準業務の
   仕様を格納する記憶装置上の標準業務テーブルを読み込
   む機能、（ｂ）該標準業務テーブルを表示装置上に表示
   する機能、および（ｃ）各業務について標準業務の仕様
   通りに標準業務を利用するか、標準業務を利用しない
   か、標準業務の仕様を修正開発した上で利用するか、標
   準業務以外の仕様の業務を追加開発するのかの区分が入
   力されたとき、業務の識別子に対応する該区分を新業務
   テーブルとして記憶装置に保存する機能。
3. 【請求項３】前記プログラムは、さらに前記（ａ）
   （ｂ）（ｃ）の機能が実行される前に前記コンピュータ
   によって実行される下記機能を含むプログラムであるこ
   とを特徴とする請求項２記載のプログラムの記憶媒体： （ａ）前記標準業務テーブルを読み込む機能、（ｂ）前
   記標準業務テーブルを表示装置上に表示する機能、およ
   び（ｃ）現状の各業務について標準業務の仕様通りに実
   施されているか、標準業務が実施されていないか、標準
   業務の仕様を修正した形態で実施されているか、標準業
   務以外の仕様の業務が実施されているかの区分が入力さ
   れたとき、業務の識別子に対応する実施状況を示す前記
   区分を記憶装置に保存する機能。
4. 【請求項４】前記プログラムは、さらに下記機能を含む
   プログラムであることを特徴とする請求項２記載のプロ
   グラムの記憶媒体： （ａ）前記新業務テーブルを読み込む機能、（ｂ）ハー
   ド／ソフトの標準導入費用の単価を格納する標準導入費
   用テーブルを読み込み、前記新業務テーブルに格納され
   る標準業務を利用する業務について入力されるハード／
   ソフトの数量から標準導入費用を計算する機能、（ｃ）
   前記新業務テーブルに格納される修正開発を要する業務
   について入力される修正開発費用に基づいて修正業務全
   体の合計を計算する機能、及び（ｄ）前記新業務テーブ
   ルに格納される追加開発を要する業務について入力され
   る追加開発費用に基づいて追加業務全体の合計を計算す
   る機能。
5. 【請求項５】前記プログラムは、さらに下記機能を含む
   プログラムであることを特徴とする請求項２記載のプロ
   グラムの記憶媒体： （ａ）前記新業務テーブルを読み込む機能、（ｂ）開発
   フェーズごとの標準の開発期間と開発人員数を格納する
   標準導入費用テーブルを読み込み、前記新業務テーブル
   に格納される標準業務を利用する業務について入力され
   る開発フェーズの開始日と担当者名に基づいて標準業務
   についての開発体制と開発日程を記憶装置に格納する機
   能、（ｃ）前記新業務テーブルに格納される修正開発業
   務について入力される開発フェーズの開始日と担当者名
   に基づいて修正開発業務についての開発体制と開発日程
   を記憶装置に格納する機能、および（ｄ）前記新業務テ
   ーブルに格納される追加開発業務について入力される開
   発フェーズの開始日と担当者名に基づいて追加開発業務
   についての開発体制と開発日程を記憶装置に格納する機
   能。