JP2008242792A - リプレース判断支援システムおよびリプレース判断支援方法 - Google Patents
リプレース判断支援システムおよびリプレース判断支援方法 Download PDFInfo
- Publication number
- JP2008242792A JP2008242792A JP2007082116A JP2007082116A JP2008242792A JP 2008242792 A JP2008242792 A JP 2008242792A JP 2007082116 A JP2007082116 A JP 2007082116A JP 2007082116 A JP2007082116 A JP 2007082116A JP 2008242792 A JP2008242792 A JP 2008242792A
- Authority
- JP
- Japan
- Prior art keywords
- business
- individual
- viewpoint
- replacement
- charge
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims description 14
- 239000000463 material Substances 0.000 claims abstract description 38
- 238000013508 migration Methods 0.000 claims abstract description 26
- 230000005012 migration Effects 0.000 claims abstract description 26
- 238000011156 evaluation Methods 0.000 claims description 39
- 238000007726 management method Methods 0.000 claims description 36
- 230000032683 aging Effects 0.000 claims description 33
- 230000007704 transition Effects 0.000 claims description 25
- 238000012545 processing Methods 0.000 claims description 22
- 230000004044 response Effects 0.000 claims description 18
- 238000012384 transportation and delivery Methods 0.000 claims description 3
- 230000008520 organization Effects 0.000 claims 1
- 230000002452 interceptive effect Effects 0.000 abstract description 16
- 230000015556 catabolic process Effects 0.000 abstract 2
- 238000006731 degradation reaction Methods 0.000 abstract 2
- 238000012423 maintenance Methods 0.000 description 24
- 230000006870 function Effects 0.000 description 16
- 230000008859 change Effects 0.000 description 13
- 238000011161 development Methods 0.000 description 12
- 230000018109 developmental process Effects 0.000 description 12
- 238000005516 engineering process Methods 0.000 description 11
- 238000012360 testing method Methods 0.000 description 7
- 238000013461 design Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 6
- 238000007792 addition Methods 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 230000008569 process Effects 0.000 description 4
- 230000009467 reduction Effects 0.000 description 4
- 208000036762 Acute promyelocytic leukaemia Diseases 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 239000000470 constituent Substances 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 230000007935 neutral effect Effects 0.000 description 2
- 238000013439 planning Methods 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 230000002829 reductive effect Effects 0.000 description 2
- 238000012552 review Methods 0.000 description 2
- 241000700605 Viruses Species 0.000 description 1
- 238000013070 change management Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000002401 inhibitory effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000003716 rejuvenation Effects 0.000 description 1
- 230000001629 suppression Effects 0.000 description 1
- 238000013509 system migration Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】システムの老朽化対応にあたって顧客の意思決定を支援する必要がある。
【解決手段】基幹システムと個別システムとを含む業務システムのリプレースを管理するリプレース管理システムにおいて、提示部12は、個別システムの老朽化対応を検討すべき段階で個別システムの移行に関する意思決定を支援する。対話型ユーザインタフェース90は、個別システムの移行に関してシステム観点から見た判断材料の入力を当該業務システムの開発者から受けつけ、個別システムの移行に関してビジネス観点から見た判断材料の入力を当該業務システムの納入先の担当者から受け付ける。システム観点選択肢提示部80は、個別システムの移行に関する客観的事実とシステム観点の価値判断材料とをもとに、システム観点から見た選択肢を提示する。ビジネス観点選択肢提示部82は、ビジネス観点の価値判断材料をもとに、ビジネス観点から見た選択肢を提示する。
【選択図】図6
【解決手段】基幹システムと個別システムとを含む業務システムのリプレースを管理するリプレース管理システムにおいて、提示部12は、個別システムの老朽化対応を検討すべき段階で個別システムの移行に関する意思決定を支援する。対話型ユーザインタフェース90は、個別システムの移行に関してシステム観点から見た判断材料の入力を当該業務システムの開発者から受けつけ、個別システムの移行に関してビジネス観点から見た判断材料の入力を当該業務システムの納入先の担当者から受け付ける。システム観点選択肢提示部80は、個別システムの移行に関する客観的事実とシステム観点の価値判断材料とをもとに、システム観点から見た選択肢を提示する。ビジネス観点選択肢提示部82は、ビジネス観点の価値判断材料をもとに、ビジネス観点から見た選択肢を提示する。
【選択図】図6
Description
この発明は、業務システムのリプレース管理技術に関する。
企業の業務システムのライフサイクルは、要求分析・仕様決定から始まり、設計、実装、テスト、運用、保守を経て、廃棄に至るまでの一連のプロセスである。要求分析の詰めが甘いと、それ以降のシステム設計、実装に顧客の要求が正しく反映されず、テストや運用段階で発見された不具合を修正するために、プログラムを改良したり、システム設計をやり直すなど、システムの保守に時間と労力を費やさなければならない。企業を取り巻く社会の変化やIT(Information Technology)技術の革新により、業務システムのライフサイクルが短くなってきており、新規システムの企画・開発に投資するのがよいか、既存システムの運用・保守に投資するのがよいかは、企業にとって重要な経営判断の一つである。
特許文献1には、設備や施設のデータをデータベース管理する設備管理システムにおいて、利用者との対話的インタフェースによるデータベース構築手段を設け、利用者自身によるデータベースの構築およびメンテナンスができるようにしたシステムが開示されている。
特開平11−85261号公報
顧客の新規ニーズに応えるための個別システムを開発し、開発された個別システムを基幹システムに連携させることで業務システムが構築されることが多いが、そのような個別システムが増えると、システム間の連携が複雑化し、業務システム全体が肥大化して、運用・保守コストが増大する。顧客としては、とりあえず新規ニーズに応える個別システムを開発して運用し、ビジネスがある程度立ち上がってくれば、正規のシステムに入れ替えればよいと考えがちである。しかし、業務システムの運用・保守にかかるコストの削減がなかなか進まない中、システムの再設計のために新たに投資することはできないのが現状であり、結局は、いったん開発された個別システムを根本的に作り直す機会などなく、最初に開発された個別システムを適宜更新しながら保守していかざるを得ない。
個別システムは、使用しているハードウェアやソフトウェアがそれぞれ異なるため、個別システムを一つ作るたびに個別の維持管理が増え、また、新機能を追加することで連携したシステムの変更箇所が増える。また各個別システムが老朽化時期を迎えれば、個別にサーバのアップグレードやソフトウェアのバージョンアップなどの老朽化対応をしていかなければならない。そのため、個別システムを多く含む業務システムは、変化が非常に緩慢なものとなり、システムの進化のスピードの低下が確実になる。このことは、業務システムが顧客ニーズの変化やIT技術の革新に応じて発展していく上で大きな障壁となっている。
また、個別システムの老朽化対応の際、システム開発者が納入先の顧客に対して一方的にシステムの移行を提案するだけでは十分ではない。顧客が最終的な意思決定に至るまでには、様々な観点で価値判断や評価がなされるため、システム開発者と顧客の間で十分なコミュニケーションを取ることが求められている。
本発明はこうした課題に鑑みてなされたものであり、その主たる目的は、業務システムのリプレースを管理する技術を提供することにある。また別の目的は、業務システムの老朽化対応に当たって利用者とのコミュニケーションを支援する技術を提供することにある。
上記課題を解決するために、本発明のある態様のリプレース判断支援システムは、基幹システムと個別ニーズに応じて作られた個別システムとを含む業務システムのリプレース判断を支援するシステムであって、個別システムの老朽化対応を検討すべき段階であるかどうかを判断する老朽化対応判断部と、前記老朽化対応判断部により個別システムの老朽化対応を検討すべき段階であると判定された場合に、個別システムの移行に関する意思決定を支援する提示部とを含む。前記提示部は、個別システムの移行に関してシステム観点から見た判断材料の入力を当該業務システムの開発者から受けつけ、個別システムの移行に関するビジネス観点から見た判断材料の入力を当該業務システムの納入先の担当者から受け付けるユーザインタフェースと、システム観点から見た場合の個別システムのリプレースに関する客観的事実と、前記開発者から提供されたシステム観点の価値判断材料とをもとに、システム観点から見た場合のとりうる選択肢を前記担当者に提示するシステム観点選択肢提示部と、前記担当者から提供されたビジネス観点の価値判断材料をもとに、ビジネス観点から見た場合のとりうる選択肢を担当者に提示するビジネス観点選択肢提示部とを含む。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラム、データ構造、記録媒体などの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、業務システムのリプレースを適切に管理して業務システムの発展を図ることができる。
図1は、実施の形態に係るリプレース管理システム100の構成図である。リプレース管理システム100は、基幹システムと個別ニーズに応じて作られた個別システムとを含む業務システムのリプレースを管理する。ここで、業務システムとは、たとえば、金融や証券などの業務を管理するシステムである。
システムの「リプレース」とは、システムを構成するサーバ等のハードウェアや、オペレーティングシステム、ミドルウェア、アプリケーション等のソフトウェアをよりよいものに改善することでシステムを更新することであり、本明細書で単に「リプレース」というときは、通常使われる意味で用いる。それとは別に、本明細書では、「単純リプレース」という用語と「再構築」という用語を用いる。
「単純リプレース」とは、リプレースの一種で、システムを構成するハードウェアやソフトウェアを極力以前と同じものを利用して性能面を増強することでインフラを更新することである。
一方、システムの「再構築」とは、新規のハードウェアやソフトウェアを導入することで、インフラを設計、構築することである。特に、個別システムを「基幹システムとして再構築する」とは、基幹システムのインフラ上に、個別システムを構築することを意味し、個別システムは基幹システムのハードウェアやソフトウェアに合わせて設計、構築し直される。なお、個別システムを基幹システムに組み込まずに、単体で新しいプラットフォームの上に移行する場合は、単に「再構築する」ということがある。
個別システムを「単純リプレースする」場合と「再構築する」場合とを包含する概念が、通常使われる意味における「リプレース」に相当する。
リプレース管理システム100は、業務システムの機器構成、オペレーティングシステムの種類とバージョン、ソフトウェア構成、トラフィックデータ、システム要件などの各種情報を記憶装置に保持しており、業務システムのリプレースのタイミングを検出したり、リプレースにかかるコストを評価することにより、業務システムのリプレースを管理する。リプレース管理システム100は、プロセッサ、メモリ、二次記憶装置をもつコンピュータシステムで構成される。リプレース管理システム100はネットワークを介してユーザの業務システムと接続され、業務システムからリプレース判断に必要な情報をネットワーク経由で取得できるように構成されてもよい。
業務システムは、個別のニーズに応じて臨機応変に開発される個別システムと、長期間運用することを前提として開発され、運用・保守される基幹システムとを含み、個別システムと基幹システムが連携して業務処理が行われる。
評価時期管理部30は、個別システムをリプレースするかどうかを評価する時期を管理する。一例として、個別システムのリプレースの評価時期を以下のように設定する。
(1)定期的チェック
たとえば、半年に一回、見直す。
(2)ユーザ数チェック
たとえば、金融システムであれば、口座数が一万に達したときに見直す。
(3)制度変更時チェック
金融や証券に関する法律の改正により、業務範囲が広がったり、顧客層が広がることがある。また、株券の電子化などの新制度の導入により顧客からの株券の持ち込みが増大することがある。このような業務に関する制度の変更時期をリプレースの評価時期に設定する。
(4)外部接続機関の仕様変更・性能増強時チェック
業務システムが接続している外部機関のシステムが仕様変更されたり、性能増強が図られるなど、外部機関のシステムのリプレース時に合わせて、個別システムをリプレースするかどうかを評価する。
(5)新製品の発表時期
ハードウェア、オペレーティングシステム、アプリケーション等の新製品が発表されると、たとえば2世代前の製品はサポート対象外となる。新製品の発表時期にサポート対象外となる世代のハードウェアやソフトウェアを使用している個別システムは、新製品の発表時期にリプレースするかどうかを評価する。
(6)新しい規格の普及時期
個別システムが独自に開発した技術が標準化されたり、デファクトスタンダードとなった場合、今後の保守を容易にするため、標準化された技術に置き換えるべきである。標準化された技術が普及する時期を個別システムのリプレースの評価時期に設定する。
(1)定期的チェック
たとえば、半年に一回、見直す。
(2)ユーザ数チェック
たとえば、金融システムであれば、口座数が一万に達したときに見直す。
(3)制度変更時チェック
金融や証券に関する法律の改正により、業務範囲が広がったり、顧客層が広がることがある。また、株券の電子化などの新制度の導入により顧客からの株券の持ち込みが増大することがある。このような業務に関する制度の変更時期をリプレースの評価時期に設定する。
(4)外部接続機関の仕様変更・性能増強時チェック
業務システムが接続している外部機関のシステムが仕様変更されたり、性能増強が図られるなど、外部機関のシステムのリプレース時に合わせて、個別システムをリプレースするかどうかを評価する。
(5)新製品の発表時期
ハードウェア、オペレーティングシステム、アプリケーション等の新製品が発表されると、たとえば2世代前の製品はサポート対象外となる。新製品の発表時期にサポート対象外となる世代のハードウェアやソフトウェアを使用している個別システムは、新製品の発表時期にリプレースするかどうかを評価する。
(6)新しい規格の普及時期
個別システムが独自に開発した技術が標準化されたり、デファクトスタンダードとなった場合、今後の保守を容易にするため、標準化された技術に置き換えるべきである。標準化された技術が普及する時期を個別システムのリプレースの評価時期に設定する。
評価時期管理部30は、上記の各種のチェックの時期を記憶装置にリプレースの評価時期として記憶しておき、各評価時期が来ると、リプレースコスト評価部10に通知する。
リプレースタイミング判定処理部20(以下、単に「判定処理部」という)は、個別システムが扱う処理量が当初のシステム要件の想定範囲を逸脱しているかどうかを調べ、逸脱した場合に、個別システムをリプレースすべきクリティカルタイミングであると判定する。判定処理部20は、クリティカルタイミングであると判定すると、リプレースコスト評価部10に通知する。また、判定処理部20は、リプレースすべきクリティカルタイミングになると、警告部22にアラートメッセージなどを表示させ、ユーザに通知する。
システム要件保持部50は、個別システムの設計当初のシステム要件が保持されている。システム要件には次のようなものがある。
(1)信頼性要件
システムは24時間稼働していなければならないなど、システムの信頼性に関する要件。
(2)運用要件
営業日のみ稼働、毎日稼働など、運用に関する要件。
(3)性能要件
一秒間に10件処理できる能力など、システムの処理性能に関する要件。
(4)データ規模要件
数千件、百万件など処理規模に関する要件。
(5)取引数量、売上金額、利益額
システムを利用する顧客の取引数量、売上げ、利益などに関する要件。
(6)システム年齢
システムが構築されてからの年数に関する要件。システム年齢は最大7年を限度とするなどの要件が定められる。
(1)信頼性要件
システムは24時間稼働していなければならないなど、システムの信頼性に関する要件。
(2)運用要件
営業日のみ稼働、毎日稼働など、運用に関する要件。
(3)性能要件
一秒間に10件処理できる能力など、システムの処理性能に関する要件。
(4)データ規模要件
数千件、百万件など処理規模に関する要件。
(5)取引数量、売上金額、利益額
システムを利用する顧客の取引数量、売上げ、利益などに関する要件。
(6)システム年齢
システムが構築されてからの年数に関する要件。システム年齢は最大7年を限度とするなどの要件が定められる。
トラフィックデータ保持部60には、過去から現在までの個別システムの処理件数や処理頻度などトラフィックに関するデータを保持している。判定処理部20は、個別システムの現在のトラフィックがシステム要件保持部50に保持されたシステム要件に合っているかどうかをチェックし、システム要件から逸脱する利用がなされている場合、個別システムをリプレースするすべきクリティカルタイミングであると判定する。判定処理部20は、トラフィックデータ保持部60に保持された過去のトラフィックデータを参照して、将来のトラフィックの増加を見込んで、クリティカルタイミングを予測してもよい。
リプレースコスト評価部10(以下、単に「コスト評価部」という)は、評価時期管理部30リプレースの評価時期の通知を受けるか、または判定処理部20からクリティカルタイミングの通知を受けたとき、個別システムを基幹システムとして再構築する場合の再構築コストを評価する。
コスト評価部10は、再構築コストを評価するにあたり、コスト関数保持部40に保持されたリプレース判断関数を用いる。リプレース判断関数は、個別システムを単純リプレースするべきか、基幹システムとして再構築するべきかを判断するための関数であり、その判断のためにリプレースにかかる下記のコストを評価する。
(1)維持管理コスト
(2)エンハンス対応コスト
(3)新規関連案件対応コスト
(4)移行コスト
以下これらのコストについて説明する。
(1)維持管理コスト
(2)エンハンス対応コスト
(3)新規関連案件対応コスト
(4)移行コスト
以下これらのコストについて説明する。
維持管理コストは、ハードウェア維持管理コストとソフトウェア維持管理コストを含む。ハードウェア・ソフトウェア維持管理コストは、障害発生率、障害ランク、平均障害対応工数、バージョンアップ発生率、平均バージョンアップ対応工数、保守契約費用などの要因を評価することで算定されるハードウェア・ソフトウェアの維持管理コストである。
エンハンス対応コストは、方式・環境・運用設計コスト、標準化コスト、ミドルウェア開発コスト、APL開発コスト、環境構築コスト、追加総合テストコスト、追加環境総合テスト(NNT)コスト、追加リリースコストなどのコストを評価することで算定される、システムのエンハンスにかかるコストである。
ここで、方式・環境・運用設計コストは、ソフトウェア製品数、新規ソフトウェア数、接続プロトコル数、新規接続プロトコル数、耐障害性要求レベル、運用時間要求レベル、性能要求レベル、データ量要求レベルなどの要因を評価することで算定されるコストである。
新規案件対応コストは、新規システムの追加に伴い、その新規システムに連携するシステムを変更するときの対応コストであり、方式・環境・運用設計コスト、設計修正規模、標準化修正規模、ミドル変更規模、APL変更規模、環境変更規模、追加総合テストコスト、追加NNTコスト、追加リリースコストなどの要因を評価することで算定される。
移行コストは、システムを新しいプラットフォームに移行するのにかかるコストである。
個別システムを単純リプレースする場合のコストは、システムのプラットフォームをグレードアップするときの維持管理コスト、エンハンス対応コスト、新規案件対応コスト、移行コストを評価することで得られる。個別システムを基幹システムとして再構築する場合のコストは、個別システムの機能を基幹システムのプラットフォームに移植したり、基幹システムに統合するときの維持管理コスト、エンハンス対応コスト、新規案件対応コスト、移行コストを評価することで得られる。
コスト評価部10は、単純リプレースコストと基幹システムへの再構築コストの比較結果を出力する。
提示部12は、個別システムを基幹システムとして再構築するか、さもなければ個別システムを廃棄するかのいずれかの二者択一を業務システムの納入先のユーザ(以下、「顧客側担当者」または単に「担当者」という)に促すために、コスト評価部10により算定された単純リプレースコストと再構築コストをメッセージを表示するなどの形で担当者に提示する。
担当者は、個別システムのリプレースの評価時期もしくはリプレースすべきクリティカルタイミングにおいて、個別システムを基幹システムとして再構築する場合のコストを提示され、再構築するか、さもなければ個別システムを廃棄するかのどちらかの選択を促される。
コスト評価部10と提示部12による個別システムのリプレースの具体的な判断例を以下に示す。
(1)個別システムを再構築する判断例
老朽化したシステムAのリプレースタイミングにおいて、以下の判断がなされる。
システムAのサーバ上の業務は今後も利用する必要があり、サーバを同等のサーバに単純に置き換える(「単純リプレース」)だけでは、今後の予想されるトラフィックの増大に耐えられない。ハードウェア・ソフトウェアのサポート切れまでの時間の余裕から、リプレース方法を検討すると、同一種類の上位サーバにリプレースする方法(「単純リプレース」)と、同一種類の上位サーバよりもさらにスケール性のある別プラットフォームに移行する方法(「再構築」)がある。コスト評価部10により、上位サーバへのアップグレードコスト(「単純リプレースコスト」)と、別プラットフォームへの移行コスト(「再構築コスト」)を比較する。コスト比較の結果は提示部12に提示され、担当者は、今後の業務面の拡大を想定して、別プラットフォームへの移行(再構築)を決断する。
老朽化したシステムAのリプレースタイミングにおいて、以下の判断がなされる。
システムAのサーバ上の業務は今後も利用する必要があり、サーバを同等のサーバに単純に置き換える(「単純リプレース」)だけでは、今後の予想されるトラフィックの増大に耐えられない。ハードウェア・ソフトウェアのサポート切れまでの時間の余裕から、リプレース方法を検討すると、同一種類の上位サーバにリプレースする方法(「単純リプレース」)と、同一種類の上位サーバよりもさらにスケール性のある別プラットフォームに移行する方法(「再構築」)がある。コスト評価部10により、上位サーバへのアップグレードコスト(「単純リプレースコスト」)と、別プラットフォームへの移行コスト(「再構築コスト」)を比較する。コスト比較の結果は提示部12に提示され、担当者は、今後の業務面の拡大を想定して、別プラットフォームへの移行(再構築)を決断する。
(2)個別システムをリプレースしないで廃棄する判断例
老朽化したシステムBのリプレースタイミングにおいて、以下の判断がなされる。
システムBのサーバ上の業務は今後も利用する必要があり、この業務と類似の業務を支えるシステムCが、別プラットフォームで稼動している。システムCを拡張してシステムBが担っていた業務にも対応することが可能である。コスト評価部10によって、システムCを拡張した場合の拡張システムの維持管理コスト増加と、システムBを単純リプレースした場合のシステムBの今後の維持管理コストとを比較する。コスト比較の結果は提示部12により提示され、担当者は、単純リプレース後のシステムBの今後の維持管理コストがシステムCの拡張による維持管理コスト増加よりも大きいことから、システムCの拡張とシステムBの既存サーバの廃止を決断する。
老朽化したシステムBのリプレースタイミングにおいて、以下の判断がなされる。
システムBのサーバ上の業務は今後も利用する必要があり、この業務と類似の業務を支えるシステムCが、別プラットフォームで稼動している。システムCを拡張してシステムBが担っていた業務にも対応することが可能である。コスト評価部10によって、システムCを拡張した場合の拡張システムの維持管理コスト増加と、システムBを単純リプレースした場合のシステムBの今後の維持管理コストとを比較する。コスト比較の結果は提示部12により提示され、担当者は、単純リプレース後のシステムBの今後の維持管理コストがシステムCの拡張による維持管理コスト増加よりも大きいことから、システムCの拡張とシステムBの既存サーバの廃止を決断する。
従来は、リプレース評価時期もしくはクリティカルタイミングにおいて、個別システムのサーバを上位機種にアップグレードするなどにより単純リプレースがなされることが多いが、そのような単純リプレースを繰り返すと、個別システムを基幹システムとして再構築する機会を失い、業務システムの複雑化、肥大化につながる。それに対して、本実施の形態では、リプレース評価時期もしくはクリティカルタイミングにおいて、単純リプレースをしないで、個別システムを基幹システムとして再構築することを再構築コストを提示して担当者に提案するため、担当者に個別システムを基幹システムに組み入れて再構築する決断する機会を与えることができる。老朽化対応時期を迎えた個別システムを基幹システムとして再構築することは、業務システム全体の運用・保守コストを下げることにつながり、先進システムの企画、開発などに投資する余裕が生まれる。
図2および図3を参照して、本実施の形態によるリプレース管理による効果を説明する。比較のため、図2は、従来の方法で業務システムのリプレースを行った場合の業務システムの発展形態を示す。図2(a)のように一台のサーバからなる最初のシステムを開発したとする。新機能に対応した個別システムを追加し、図2(b)のような3台のサーバからなる連携システムが開発される。以後、新機能を追加するたびに新しい個別システムを追加していくと、図2(c)のように多数のサーバが複雑に接続された連携システムが形成される。同図はサーバ間の物理的な接続関係を示すが、論理的なシステム間のつながりはさらに複雑なものとなる。このような複雑な連携システムを運用・保守するにはたいへんな労力を要する。
図3は、本実施の形態のリプレース管理システム100を用いた場合の業務システムの発展形態を示す。個別システムは捨てる前提で開発され、老朽化対応時期が来ると、リプレース管理システム100は個別システムを基幹システムとして再構築することをユーザに提案する。
図3(a)に示すように、業務システムを個別システムと基幹システムに分けて設計する。個別システムは、その時々のニーズに合わせて作り変えるシステムであり、半ば捨てる前提で保守期間を気にせず新しい技術を使って開発される。基幹システムは、長期的なビジネスを支えるために開発されるものであり、使い続ける前提で保守期間の長いハードウェア・ソフトウェアを用いて作られ、規模拡大に備えて継続的に整理・統合される。
個別システムは、リプレースのタイミングが来ると、位置づけを変更して基幹システムに組み入れるために再構築するか、さもなければ廃棄する。同図では、符号200aで示す個別システムは基幹システムとして再構築され、符号200bで示す個別システムは廃棄される。
このようにして、各個別システムのリプレース判断時点で、基幹システムに組み入れるか、廃棄するかの二者択一をユーザに迫るようにすれば、新規ニーズに応じて次々に個別システムが開発、追加されても、業務システムが複雑化、肥大化するのを防ぐことができる。図3(b)は、個別システムが多数追加されて発展した業務システムの形態を示す。増え続ける個別システム群については、各個別システムの老朽化対応時期に廃棄されるか、基幹システムとして再構築されるため、基幹システムとの接続関係は複雑にならない。一方、基幹システムは適宜個別システムの機能を取り入れながら整備されていく。個別システムが増えていっても、個別システムと基幹システムの境界が保たれるため、運用・保守が容易である。
上記の実施の形態のリプレース管理システム100において、個別システムをリプレースすべきクリティカルタイミングは、トラフィック予測にもとづいて判定されてもよい。図4および図5を参照して、トラフィック予測にもとづいてクリティカルタイミングを判定するための判定処理部20の構成と動作について説明する。
図4は、判定処理部20の構成図である。ピーク検出部70は、トラフィックデータ保持部60から個別システムの過去のトラフィックデータを取得し、トラフィック変動のピーク群を抽出する。
図5に示すように、一般に業務システムのトラフィック量は何度かのピークを迎えながら増えていくことが経験的に知られている。たとえば、証券システムでは、市場の期待感の高まりからトラフィックが増えていき、相乗効果からピークを迎える。その後、市場の興奮が収まるにつれてトラフィックが減少するが、再び市場で期待感が高まると次のピークに向かってトラフィックが成長する。
ピーク検出部70は、抽出したトラフィックのピーク群をもとに、ピークの高さλと出現周期Tを検出する。図5の例では、符号210で示すトラフィック変動において白丸で示したトラフィックのピーク群220a、220b、220cが抽出され、ピークの高さλ1、λ2と、ピークの出現周期T1、T2が検出される。
ピーク推定部72は、検出されたピークの高さλ1、λ2と出現周期T1、T2をもとに、次に起こるべきピークの高さλ3と出現周期T3を推定する。ピーク推定部72は、点線230で示すようにピーク間に近似曲線を当てはめて補間することで次のピークを推定してもよい。これにより、次のピークの発生タイミングtdとそのときのトラフィック量Xd(図中のピーク220d)が推定される。
クリティカルトラフィック設定部74は、個別システムを基幹システムとして再構築するためにかかる時間Lをコスト評価部10から取得する。これはシステム再構築のいわゆる「リードタイム」である。クリティカルトラフィック設定部74は、次に起こるピークの推定タイミングtdからシステム再構築のリードタイムLだけ遡ったタイミングtcにおけるトラフィック量Xcをトラフィック変動曲線210にしたがって求め、このトラフィック量Xcを、個別システムのリプレースを検討すべきクリティカルトラフィック量に設定する。
クリティカルタイミング判定部76は、トラフィックデータ保持部60から読み出した個別システムのトラフィックがクリティカルトラフィック量Xcに達するときを、個別システムをリプレースすべきクリティカルタイミングと判定し、コスト評価部10と警告部22に通知する。
このように、図4に示した判定処理部20のトラフィック推定機能により、将来のピークに備えて、システム再構築のリードタイムも考慮に入れてあらかじめ個別システムをリプレースすべきクリティカルタイミングを判定することができ、トラフィックの急成長に対して予防的に対処して、個別システムの再構築をユーザに提案することができる。
上記の説明では、提示部12は、単純リプレースコストと比較する形で再構築コストを提示することにより、個別システムを基幹システムとして再構築するか、さもなければ廃棄するかの二者択一をユーザに迫った。しかし、再構築コストの提示だけでユーザに二者択一の意思決定をすることは現実には難しいことがある。そこで、提示部12は、ユーザの二者択一の意思決定を支援するために、対話型のユーザインタフェースを備えてもよい。以下、提示部12がもつ対話型ユーザインタフェース機能について詳しく説明する。
図6は、提示部12の機能構成図である。提示部12は、システム観点選択肢提示部80、ビジネス観点選択肢提示部82、および対話型ユーザインタフェース90を有する。図1のリプレースタイミング判定処理部20、評価時期管理部30は、個別システムの老朽化対応を検討すべき段階であるかどうかを判断する「老朽化対応判断部」の一例である。提示部12は、老朽化対応を検討すべき段階であると判断された個別システムについて、システム観点とビジネス観点の両方から見た場合のリプレースに関する価値判断材料の入力を支援する。
上記の説明では、図1のリプレースコスト評価部10は、老朽化対応時期を迎えた個別システムについて、単純リプレースコストと再構築コストを出力したが、ここでは、ユーザの意思決定を支援するために、リプレースに関するコストだけでなく、システム観点から見た場合のリプレースに関する客観的な事実全般を提示部12に与える。
老朽化対応時期を迎えた個別システムについてのシステム観点から見たリプレースに関する客観的事実として、移行を促進するもの、抑制するもの、中立的であるものに分けると、以下のような項目がある。
(1)システム観点から見たリプレースに関する客観的事実
(1−1)移行を促進する事実
ハードウェア、ソフトウェアのサポート切れ、
ハードウェア、ソフトウェアのバグ、セキュリティホールの発生または発生頻度、
移行コストの増加量、新規案件対応コストの増加量、
維持管理コストの増加量、エンハンス対応コストの増加量、
担当チームの老齢化と移行による担当チームの若返り、
担当チームのシステム把握度低下と移行による担当チームのシステム把握度向上、
限界性能を超える負荷の到来。
(1−1)移行を促進する事実
ハードウェア、ソフトウェアのサポート切れ、
ハードウェア、ソフトウェアのバグ、セキュリティホールの発生または発生頻度、
移行コストの増加量、新規案件対応コストの増加量、
維持管理コストの増加量、エンハンス対応コストの増加量、
担当チームの老齢化と移行による担当チームの若返り、
担当チームのシステム把握度低下と移行による担当チームのシステム把握度向上、
限界性能を超える負荷の到来。
一般に、個別システムを新しいプラットフォームに移行させてシステムを再構築する際、担当チームが入れ替わることが多く、担当チームのメンバー構成が若返ることがある。また、移行を機に担当者のシステムの理解度が一気に高まる。
(1−2)移行を抑制する事実
移行後に想定される、維持管理コスト、エンハンス対応コスト、新規関連案件対応コスト、移行コスト、およびこれらの増加量
移行後に想定される、維持管理コスト、エンハンス対応コスト、新規関連案件対応コスト、移行コスト、およびこれらの増加量
個別システムを新しいプラットフォームに移行すると、コスト評価部10が用いるリプレース判断のために評価していた維持管理コスト、エンハンス対応コスト、新規関連案件対応コストおよび移行コストが変わる。コスト評価部10は移行後の個別システムについてこれらのコストを求め、移行前のコストからの増加量を算定する。
(1−3)中立的な事実
システムの使用年数、システムの償却年数。
システムの使用年数、システムの償却年数。
個別システムの開発者は、対話型ユーザインタフェース90を介して、老朽化対応時期を迎えた個別システムについて、システム観点から見た場合のリプレースに関する主観的な価値判断材料を提供する。システム観点から見たリプレースに関する主観的価値判断材料として、移行を促進するもの、抑制するものに分けると、以下のような項目がある。
(2)システム観点から見たリプレースに関する主観的価値判断材料
(2−1)移行促進材料
新技術の登場・普及、
新標準の登場・普及、
新機能追加要望、
新たなシステム間接続、
担当チームのリソース余剰、
担当チームの変更・追加による担当チームのスキルセットの変化(たとえばプログラミング言語が変更される場合の担当者チームがもつプログラミング技術の変化)。
(2−1)移行促進材料
新技術の登場・普及、
新標準の登場・普及、
新機能追加要望、
新たなシステム間接続、
担当チームのリソース余剰、
担当チームの変更・追加による担当チームのスキルセットの変化(たとえばプログラミング言語が変更される場合の担当者チームがもつプログラミング技術の変化)。
(2−2)移行抑制材料
移行によって新たなバグが作りこまれるなどシステムの安定性の変化、
担当チームのリソース不足、
新制度への対応を含む計画済みのエンハンス。
移行によって新たなバグが作りこまれるなどシステムの安定性の変化、
担当チームのリソース不足、
新制度への対応を含む計画済みのエンハンス。
システム観点選択肢提示部80は、コスト評価部10から入力されたシステム観点のリプレースに関する客観的事実と、開発者から対話型ユーザインタフェース90を介して提供されたシステム観点の主観的な価値判断材料とをもとに、システム観点から見た場合のとりうる選択肢を当該業務システムのユーザ(顧客側の担当者)に提示する。システム観点の選択肢として、移行を促進するもの、抑制するものに分けると、以下の選択肢がある。
(3)システム観点から見た選択肢
(3−1)移行促進
個別再構築、
共通基盤への再構築、
サービスレベル変更(たとえば24時間稼働から平日の日中稼働に変更するなど)、
システム統合(たとえば一台のマシンで3つのシステムを実行させるなど)、
システム廃止(個別システムは破棄し、基幹システムを拡張するなど)。
(3−1)移行促進
個別再構築、
共通基盤への再構築、
サービスレベル変更(たとえば24時間稼働から平日の日中稼働に変更するなど)、
システム統合(たとえば一台のマシンで3つのシステムを実行させるなど)、
システム廃止(個別システムは破棄し、基幹システムを拡張するなど)。
ここで、個別再構築、共通基盤(基幹システム)への再構築には、即時再構築、一定期間内に再構築、トラフィックが特定条件を満たしたときに再構築などのバリエーションがある。
(3−2)移行抑制
単純リプレース、
現状のまま継続。
単純リプレース、
現状のまま継続。
個別システムの顧客側の担当者は、対話型ユーザインタフェース90を介して、システム開発者が提示したシステム観点のリプレースに関する主観的な価値判断材料に対して重み付けを与えることができる。システム観点選択肢提示部80は、顧客側担当者が与えた重み付けにしたがって、システム観点の選択肢に優先順位を付けて提示することもできる。
顧客側の担当者は、さらに、老朽化対応時期を迎えた個別システムについて、企業のビジネス観点から見た場合のリプレースに関する主観的な価値判断材料を対話型ユーザインタフェース90を介して提供する。ビジネス観点から見たリプレースに関する主観的な価値判断材料として、移行を促進するもの、抑制するものに分けると、以下のような項目がある。
(4)ビジネス観点から見たリプレースに関する主観的な価値判断材料
(4−1)移行促進材料
コスト抑制圧力(外部要因、経営目標など)、
業務提携などに伴う当該業務の位置付け変化(業務の重要度の上昇または低下、業務形態変化、業務廃止など)、
予算の余剰、予想外の利益。
(4−1)移行促進材料
コスト抑制圧力(外部要因、経営目標など)、
業務提携などに伴う当該業務の位置付け変化(業務の重要度の上昇または低下、業務形態変化、業務廃止など)、
予算の余剰、予想外の利益。
(4−2)移行抑制材料
予算不足
予算不足
たとえば、証券業務の自由化により、新しい金融商品が生まれたり、証券業務への新規参入が可能となるなど、ビジネスを取り巻く環境が大きく変化し、ビジネスチャンスが期待できる状況は、ビジネス観点から見て移行を促進する材料として働く。
ビジネス観点選択肢提示部82は、顧客側の担当者から対話型ユーザインタフェース90を介して提供されたビジネス観点の主観的な価値判断材料をもとに、ビジネス観点から見た場合のとりうる選択肢を担当者に提示する。ビジネス観点選択肢提示部82は、システム観点選択肢提示部80からシステム観点の選択肢の入力を受けており、システム観点の選択肢とともにビジネス観点の選択肢を提示する。ビジネス観点の選択肢には以下のようなものがある。
(5)ビジネス観点の選択肢
予算追加または削減
人員追加または削減
業務フローの高度化または単純化
業務品質の向上または低減
予算追加または削減
人員追加または削減
業務フローの高度化または単純化
業務品質の向上または低減
個別システムの顧客側の担当者は、対話型ユーザインタフェース90を介して、ビジネス観点のリプレースに関する主観的な価値判断材料に対して重み付けを与えることができる。ビジネス観点選択肢提示部82、顧客側担当者が与えた重み付けにしたがって、ビジネス観点の選択肢に優先順位を付けて提示することもできる。
システム観点選択肢提示部80が提示するシステム観点の選択肢は、業務システムの顧客側の担当者向けであるのに対して、ビジネス観点選択肢提示部82が提示するビジネス観点の選択肢は、企業の経営者向けである。老朽化対応時期を迎えた個別システムの再構築の意思決定を促すためには、再構築の必要性を顧客側担当者に訴えるだけでなく、経営者に訴えることも重要となる。
そこで、顧客側担当者向けに再構築の必要性を説得するためのキーワードや文章などのフレーズと、企業経営者向けに再構築の必要性を説得するためのフレーズとをそれぞれ用意しておき、システム観点の選択肢を提示するときには顧客側担当者向けのフレーズを添えるようにし、ビジネス観点の選択肢を提示するときには企業経営者向けのフレーズを添えるようにすることが一層効果的である。
担当者向けフレーズ記憶部84は、顧客側担当者向けのフレーズを格納しており、システム観点選択肢提示部80は、システム観点の各選択肢に適した担当者向けフレーズを担当者向けフレーズ記憶部84から読み出し、選択肢を提示する際に利用する。担当者向けフレーズは、たとえば、開発期間、開発コスト、先進技術、新機能に関するものであり、「再構築すると開発コストが下がる」、「先進技術を用いることで開発期間が短縮される」など、担当者にアピールするキーワードを用いた文章である。このようなフレーズを用いることでシステム観点から見た選択肢を担当者にとってより説得力のあるものにすることができる。
経営者向けフレーズ記憶部86は、担当者の上司や経営者向けのフレーズを格納しており、ビジネス観点選択肢提示部82は、ビジネス観点の各選択肢に適した経営者向けフレーズを経営者向けフレーズ記憶部86から読み出し、選択肢を提示する際に利用する。経営者向けフレーズは、たとえば、ビジネスニーズへの合致、TCO(総所有コスト)、安定性、法令遵守、監査性に関するものであり、「今、再構築に投資することによって運用・保守の無駄な経費が抑制され、TCO削減につながる」、「ここで再構築しておかなければ、ビジネスニーズに応えられず、ビジネスチャンスを失う」、「法令遵守(コンプライアンス)のためには新規システムに移行する必要がある」など、経営者にアピールするキーワードを用いた文章である。このようなフレーズを用いてビジネス観点の選択肢を提示することで、担当者が上司や経営者に説得力のある説明をすることができるようになる。
システム観点選択肢提示部80とビジネス観点選択肢提示部82により、システム観点およびビジネス観点からの選択肢が提示され、顧客側担当者が対話型ユーザインタフェース90を用いて、システム観点およびビジネス観点の主観的な価値判断材料の重み付けを変更していくことで、最終的に個別システムを単純リプレースするのか、再構築するのか、それとも破棄するのかといった意思決定をしていくことができる。また、システム開発者がシステム観点の主観的な価値判断を入力し、顧客側担当者がビジネス観点の主観的な価値判断を入力するため、システム開発者と顧客担当者の価値判断の違いをとりうる選択肢の優先度に反映させることができる。
以下、対話型ユーザインタフェース90を用いた判断事例を挙げる。
(1)システム観点では移行すべきと考えられるが、ビジネス観点まで考えると今は移行すべきではないと判断された事例
(1−1)システム観点の判断
オペレーティングシステムのサポート切れが6箇月後に迫ったサーバAがあった。システム観点選択肢提示部80には、このようなサーバのサポート切れの情報がシステム観点のリプレースに関する客観的事実として入力される。
オペレーティングシステムのサポート切れとなると、それ以降、オペレーティングシステムのバグやセキュリティホールに対するパッチが提供されないなどの不具合が予想される。システム開発者はこういったシステム観点から見た主観的な判断材料を対話型ユーザインタフェース90を介してシステム観点選択肢提示部80に与える。
システム観点選択肢提示部80は、サポート切れという客観的事実とサポート切れに伴う不具合についての主観的判断材料をもとに、システム観点の選択肢として、6箇月以内の早期移行を顧客側担当者に推奨した。
(1)システム観点では移行すべきと考えられるが、ビジネス観点まで考えると今は移行すべきではないと判断された事例
(1−1)システム観点の判断
オペレーティングシステムのサポート切れが6箇月後に迫ったサーバAがあった。システム観点選択肢提示部80には、このようなサーバのサポート切れの情報がシステム観点のリプレースに関する客観的事実として入力される。
オペレーティングシステムのサポート切れとなると、それ以降、オペレーティングシステムのバグやセキュリティホールに対するパッチが提供されないなどの不具合が予想される。システム開発者はこういったシステム観点から見た主観的な判断材料を対話型ユーザインタフェース90を介してシステム観点選択肢提示部80に与える。
システム観点選択肢提示部80は、サポート切れという客観的事実とサポート切れに伴う不具合についての主観的判断材料をもとに、システム観点の選択肢として、6箇月以内の早期移行を顧客側担当者に推奨した。
(1−2)ビジネス観点の判断
一方、当該サーバA上の業務は、1年後に社内制度の変更により見直しが予定されている。このようなエンハンスの計画はシステム開発者は知らないため、システム観点の判断段階では考慮に入れることができなかった。顧客側担当者はこのようなビジネス観点の判断材料を対話型ユーザインタフェース90を介してビジネス観点選択肢提示部82に与えることができる。ビジネス観点選択肢提示部82は、1年後の社内制度の変更タイミングでアプリケーションの修正を行うことをビジネス観点の選択肢として提示する。
一方、当該サーバA上の業務は、1年後に社内制度の変更により見直しが予定されている。このようなエンハンスの計画はシステム開発者は知らないため、システム観点の判断段階では考慮に入れることができなかった。顧客側担当者はこのようなビジネス観点の判断材料を対話型ユーザインタフェース90を介してビジネス観点選択肢提示部82に与えることができる。ビジネス観点選択肢提示部82は、1年後の社内制度の変更タイミングでアプリケーションの修正を行うことをビジネス観点の選択肢として提示する。
(1−3)ビジネス観点を鑑みたシステム観点の判断の再考
顧客側担当者は、システム観点選択肢提示部80が提示するサポート切れになる前の6箇月以内の早期移行と、ビジネス観点選択肢提示部82が提示する1年後の社内制度の変更タイミングでの移行の2つの選択肢を提示される。当該サーバAは、数年前にコンピュータセンタ内に設置され、社内利用に閉じる使い方をしている。このため、新たなオペレーティングシステムのバグが発生する可能性や、ウィルス等によるセキュリティ上の脅威は、可能性が低いと考えることができる。顧客側担当者は、これらを鑑み、6箇月後から1年後まではオペレーティングシステムのサポート切れの状態で利用を継続し、1年後に移行することを意思決定した。
顧客側担当者は、システム観点選択肢提示部80が提示するサポート切れになる前の6箇月以内の早期移行と、ビジネス観点選択肢提示部82が提示する1年後の社内制度の変更タイミングでの移行の2つの選択肢を提示される。当該サーバAは、数年前にコンピュータセンタ内に設置され、社内利用に閉じる使い方をしている。このため、新たなオペレーティングシステムのバグが発生する可能性や、ウィルス等によるセキュリティ上の脅威は、可能性が低いと考えることができる。顧客側担当者は、これらを鑑み、6箇月後から1年後まではオペレーティングシステムのサポート切れの状態で利用を継続し、1年後に移行することを意思決定した。
このようにして、システム開発者によるシステム観点からの見解が顧客側担当者によるビジネス観点の見解によって修正される。システム開発者の一方的な考えだけで移行すべきかどうかが判断されるのではなく、顧客側の事情や意見も採り入れて最終的に意思決定される。
(2)システム観点では移行すべきではないが、ビジネス観点まで考えると移行すべきであると判断された事例
(2−1)システム観点の判断
システムとして安定しているシステムAとシステムBがある。システムBはシステムAと連携して稼動している。ビジネスの拡大に伴って、システムAの機能拡充・キャパシティ拡大が予定されている。システム観点選択肢提示部80には、このようなシステムの稼働状況や機能拡張予定などの客観的事実が入力される。
システム開発者は、このような状況に鑑みて、システムAの刷新に伴い、強力かつ保守年限の長いサーバを導入することにし、システムBについては、当面、機能拡充やキャパシティ拡大は不要であると判断した。システム観点選択肢提示部80にはシステム開発者によるこのようなシステム観点からの価値判断が入力される。
システム観点選択肢提示部80は、システム観点の客観的事実とシステム観点の価値判断材料をもとに、現時点では、システムBの移行は不要であるという判断を顧客側担当者に提示した。
(2−1)システム観点の判断
システムとして安定しているシステムAとシステムBがある。システムBはシステムAと連携して稼動している。ビジネスの拡大に伴って、システムAの機能拡充・キャパシティ拡大が予定されている。システム観点選択肢提示部80には、このようなシステムの稼働状況や機能拡張予定などの客観的事実が入力される。
システム開発者は、このような状況に鑑みて、システムAの刷新に伴い、強力かつ保守年限の長いサーバを導入することにし、システムBについては、当面、機能拡充やキャパシティ拡大は不要であると判断した。システム観点選択肢提示部80にはシステム開発者によるこのようなシステム観点からの価値判断が入力される。
システム観点選択肢提示部80は、システム観点の客観的事実とシステム観点の価値判断材料をもとに、現時点では、システムBの移行は不要であるという判断を顧客側担当者に提示した。
(2−2)ビジネス観点の判断
一方、顧客側担当者は、システムBのサーバが設置されている部屋は狭く、システムAのサーバが設置されている部屋は広いなどの事情から、この機会にシステムBをシステムAと同じサーバに移行しておけば、今後、キャパシティ拡大があった場合にも対応できると判断した。また、システムAをテストするタイミングで、システムBのテストもかなりの範囲実施することとなるため、システムBをシステムAと同時に移行する場合にかかる移行コストは、システムBを単独で移行する場合の移行コストの合計に比べて低いことがわかった。ビジネス観点選択肢提示部82には、顧客側担当者のこのようなビジネス観点の価値判断材料が入力される。ビジネス観点選択肢提示部82は、システムBをシステムAのプラットフォーム提供者に移行することをビジネス観点の選択肢として提示する。
一方、顧客側担当者は、システムBのサーバが設置されている部屋は狭く、システムAのサーバが設置されている部屋は広いなどの事情から、この機会にシステムBをシステムAと同じサーバに移行しておけば、今後、キャパシティ拡大があった場合にも対応できると判断した。また、システムAをテストするタイミングで、システムBのテストもかなりの範囲実施することとなるため、システムBをシステムAと同時に移行する場合にかかる移行コストは、システムBを単独で移行する場合の移行コストの合計に比べて低いことがわかった。ビジネス観点選択肢提示部82には、顧客側担当者のこのようなビジネス観点の価値判断材料が入力される。ビジネス観点選択肢提示部82は、システムBをシステムAのプラットフォーム提供者に移行することをビジネス観点の選択肢として提示する。
(2−3)ビジネス観点を鑑みたシステム観点の判断の再考
顧客側担当者は、システム観点選択肢提示部80がシステム観点から提示する移行不要の選択肢に対して、ビジネス観点選択肢提示部82がビジネス観点から提示する移行推奨の選択肢を優先して、システムBは早めに除却し、システムAとあわせてシステムBを新サーバへ移行する決定を最終的に行った。
顧客側担当者は、システム観点選択肢提示部80がシステム観点から提示する移行不要の選択肢に対して、ビジネス観点選択肢提示部82がビジネス観点から提示する移行推奨の選択肢を優先して、システムBは早めに除却し、システムAとあわせてシステムBを新サーバへ移行する決定を最終的に行った。
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
リプレース管理システム100において、ITIL(Information Technology Infrastructure Library)管理を導入してもよい。ITIL管理では、ハードウェア、ソフトウェア、アプリケーション、ネットワークなどの構成要素を管理する「構成管理」、システムリリース後の変更履歴を管理する「変更管理」、障害の履歴を管理する「インシデント管理」などが行われる。ITIL管理の各種情報をリプレースの際の判断材料に用いることができる。
10 リプレースコスト評価部、 12 提示部、 20 リプレースタイミング判定処理部、 22 警告部、 30 評価時期管理部、 40 コスト関数保持部、 50 システム要件保持部、 60 トラフィックデータ保持部、 70 ピーク検出部、 72 ピーク推定部、 74 クリティカルトラフィック設定部、 76 クリティカルタイミング判定部、 80 システム観点選択肢提示部、 82 ビジネス観点選択肢提示部、 84 担当者向けフレーズ記憶部、 86 経営者向けフレーズ記憶部、 90 対話型ユーザインタフェース、 100 リプレース管理システム。
Claims (6)
- 基幹システムと個別ニーズに応じて作られた個別システムとを含む業務システムのリプレース判断を支援するシステムであって、
個別システムの老朽化対応を検討すべき段階であるかどうかを判断する老朽化対応判断部と、
前記老朽化対応判断部により個別システムの老朽化対応を検討すべき段階であると判定された場合に、個別システムの移行に関する意思決定を支援する提示部とを含み、
前記提示部は、
個別システムの移行に関してシステム観点から見た判断材料の入力を当該業務システムの開発者から受けつけ、個別システムの移行に関してビジネス観点から見た判断材料の入力を当該業務システムの納入先の担当者から受け付けるユーザインタフェースと、
システム観点から見た場合の個別システムの移行に関する客観的事実と、前記開発者から提供されたシステム観点の価値判断材料とをもとに、システム観点から見た場合のとりうる選択肢を前記担当者に提示するシステム観点選択肢提示部と、
前記担当者から提供されたビジネス観点の価値判断材料をもとに、ビジネス観点から見た場合のとりうる選択肢を担当者に提示するビジネス観点選択肢提示部とを含むことを特徴とするリプレース判断支援システム。 - 前記担当者向けに移行を推奨するフレーズと、経営者向けに移行を推奨するフレーズとをあらかじめ用意して格納したフレーズ記憶部をさらに設け、
前記システム観点選択肢提示部は、システム観点の選択肢を提示する際、前記フレーズ記憶部から担当者向けフレーズを読み出して選択肢とともに提示し、
前記ビジネス観点選択肢提示部は、ビジネス観点の選択肢を提示する際、前記フレーズ記憶部から経営者向けフレーズを読み出して選択肢とともに提示することを特徴とする請求項1に記載のリプレース判断支援システム。 - 前記老朽化対応判断部は、
個別システムをリプレースするかどうかを評価する時期を管理する評価時期管理部と、
個別システムが扱う処理量が当初のシステム要件の想定範囲を逸脱した場合に、個別システムをリプレースすべきクリティカルタイミングであると判定する判定処理部とを含み、
前記老朽化対応判断部は、前記評価時期管理部からリプレースの評価時期の通知を受けるか、または前記判定処理部からクリティカルタイミングの通知を受けたとき、個別システムの老朽化対応を検討すべき段階であると判断することを特徴とする請求項1または2に記載のリプレース判断支援システム。 - 前記評価時期管理部は、個別システムのリプレースの評価時期を、業務に関する制度の変更時期に設定することを特徴とする請求項3に記載のリプレース判断支援システム。
- 前記評価時期管理部は、個別システムのリプレースの評価時期を、当該個別システムが接続されている外部機関のシステムのリプレース時期に設定することを特徴とする請求項3に記載のリプレース判断支援システム。
- 基幹システムと個別ニーズに応じて作られた個別システムとを含む業務システムのリプレース判断を支援する方法であって、
個別システムの老朽化対応を検討すべき段階であるかどうかを判断する老朽化対応判断ステップと、
前記老朽化対応判断ステップにおいて個別システムの老朽化対応を検討すべき段階であると判定された場合に、個別システムの移行に関する意思決定を支援する意思決定支援ステップとを含み、
前記意思決定支援ステップは、
ユーザインタフェースを介して、個別システムの移行に関してシステム観点から見た判断材料の入力を当該業務システムの開発者から受けつけ、個別システムの移行に関してビジネス観点から見た判断材料の入力を当該業務システムの納入先の担当者から受け付けるステップと、
システム観点から見た場合の個別システムのリプレースに関する客観的事実と、前記開発者から提供されたシステム観点の価値判断材料とをもとに、システム観点から見た場合のとりうる選択肢を前記担当者に提示するステップと、
前記担当者から提供されたビジネス観点の価値判断材料をもとに、ビジネス観点から見た場合のとりうる選択肢を担当者に提示するステップとを含むことを特徴とするリプレース判断支援方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007082116A JP2008242792A (ja) | 2007-03-27 | 2007-03-27 | リプレース判断支援システムおよびリプレース判断支援方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007082116A JP2008242792A (ja) | 2007-03-27 | 2007-03-27 | リプレース判断支援システムおよびリプレース判断支援方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2008242792A true JP2008242792A (ja) | 2008-10-09 |
Family
ID=39914065
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007082116A Pending JP2008242792A (ja) | 2007-03-27 | 2007-03-27 | リプレース判断支援システムおよびリプレース判断支援方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2008242792A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008242791A (ja) * | 2007-03-27 | 2008-10-09 | Nomura Research Institute Ltd | リプレース管理システムおよびリプレース管理方法 |
WO2010032480A1 (ja) | 2008-09-22 | 2010-03-25 | 信越ポリマー株式会社 | 導電性高分子溶液、導電性塗膜および入力デバイス |
JP2012008668A (ja) * | 2010-06-23 | 2012-01-12 | Japan Research Institute Ltd | 移行計画作成支援装置、移行計画作成方法、およびプログラム |
JP2015165363A (ja) * | 2014-03-03 | 2015-09-17 | 日本電気株式会社 | スケジューリング装置、スケジューリング方法、及び、スケジューリングプログラム |
JP2020052854A (ja) * | 2018-09-28 | 2020-04-02 | 日本電気株式会社 | 情報処理装置、情報処理システム、情報処理方法、及びプログラム。 |
-
2007
- 2007-03-27 JP JP2007082116A patent/JP2008242792A/ja active Pending
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008242791A (ja) * | 2007-03-27 | 2008-10-09 | Nomura Research Institute Ltd | リプレース管理システムおよびリプレース管理方法 |
WO2010032480A1 (ja) | 2008-09-22 | 2010-03-25 | 信越ポリマー株式会社 | 導電性高分子溶液、導電性塗膜および入力デバイス |
JP2012008668A (ja) * | 2010-06-23 | 2012-01-12 | Japan Research Institute Ltd | 移行計画作成支援装置、移行計画作成方法、およびプログラム |
JP2015165363A (ja) * | 2014-03-03 | 2015-09-17 | 日本電気株式会社 | スケジューリング装置、スケジューリング方法、及び、スケジューリングプログラム |
JP2020052854A (ja) * | 2018-09-28 | 2020-04-02 | 日本電気株式会社 | 情報処理装置、情報処理システム、情報処理方法、及びプログラム。 |
JP7200577B2 (ja) | 2018-09-28 | 2023-01-10 | 日本電気株式会社 | 情報処理装置、情報処理システム、情報処理方法、及びプログラム。 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9292421B2 (en) | System and method for resource modeling and simulation in test planning | |
Suryn | Software quality engineering: a practitioner's approach | |
Bennett | Software evolution: past, present and future | |
US20080270213A1 (en) | Process risk estimation indication | |
Renault et al. | A Pattern-based Method for building Requirements Documents in Call-for-tender Processes | |
US10417712B2 (en) | Enterprise application high availability scoring and prioritization system | |
JP2008242792A (ja) | リプレース判断支援システムおよびリプレース判断支援方法 | |
Wolski et al. | Software quality model for a research‐driven organization—An experience report | |
Staron | Dashboard development guide How to build sustainable and useful dashboards to support software development and maintenance | |
CN114911492A (zh) | 推理服务部署方法、装置、设备以及存储介质 | |
JP4878568B2 (ja) | リプレース管理システムおよびリプレース管理方法 | |
Jung et al. | A systematic software development process for non-functional requirements | |
Ebad | The influencing causes of software unavailability: A case study from industry | |
Çalikli et al. | Measure early and decide fast: transforming quality management and measurement to continuous deployment | |
Ghaffarzadegan et al. | Dell's SupportAssist customer adoption model: enhancing the next generation of data‐intensive support services | |
CN113535560B (zh) | 测试执行方法、装置、存储介质和计算设备 | |
Zaineb et al. | Identification and analysis of causes for software bug rejection with their impact over testing efficiency | |
Paech et al. | An Experience-Based Approach for Integrating Architecture and Requirements Engineering. | |
Ferreira | Measuring the effects of requirements volatility on software development projects | |
KR101981201B1 (ko) | 보험사대리점서버에 비즈니스 룰을 구현하기 위한 방법 및 그 방법을 구현하기 위한 시스템 | |
Den Boer | Six Sigma for IT management | |
Taylor | Autonomic Business Processes | |
Wohlrab et al. | Experience of pragmatically combining RE methods for performance requirements in industry | |
Galinec et al. | The impact of application non-functional requirements on enterprise architecture | |
Horkoff et al. | Strategic API analysis and planning: APIS technical report |