 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||
|
||||||||||||||
| マスタープランに基づく移行 | ||||||||||||||
|
A製鉄所のようなシステム全般に渡るマイグレーション（Rebuild）は、1年や2年でその完遂を目標としたものではない。リスク、投資効果、技術の成熟状況、製鉄所の設備増強とのタイミングなどを総合的に考慮し、数年のオーダーで段階的に移行していくことを想定している。 鉄鋼における生産管理システムを概観したものを表1に示す。
表1：鉄鋼生産管理システム概観 このうち計画系に近い機能ほど（高い信頼性を求められることには変わりはないが）、システム障害復旧に対しての時間的猶予がある。またメインフレーム中心構造に、「シミュレーション機能」や「対話系機能」などのオープン環境を追加するような「メインフレーム＋オープンシステム」の連携環境では、オープン系のデータ回復にデータベースをメインフレームから再作成することもできる。 一方、分単位で機会損失を生む操業系の分野については、より高い信頼性、高可用性、高応答性での運用を可能とする技術の利用が必要となり、リスクは格段に高くなる。 |
||||||||||||||
| STEP移行の推奨 | ||||||||||||||
|
そこでA製鉄所では、まずトラブルに対して若干の余裕がある生産計画系システムを対象にマイグレーションを実行し、これらの作業を通じてオープン系技術を24時間365日稼動する操業系システムに適用するという見極めをつけた。 そして、操業系システムのマイグレーションを一気に行うのではなく、圧延からはじまる各種の加工・精整を経て倉庫に入る一連のプロセスのうち、まずは最後尾である倉庫機能から行うこととした。 なおこのような段階的移行を採用する場合、異なる環境間のデータの整合性確保が課題となる。メインフレームとオープンシステム間のデータ連携や、同じオープン環境同士でも（やむをえない事情で）異なっているRDB製品間での連携方式を確立する必要があるのだ。 操業ロスをミニマムにするためには短時間でシステム切り替えを実現する機構も必須であった。他にも基本的なオープン環境基盤の安定性の確保や、並行テストによる綿密な検証計画など検討すべき課題は多かったが、当社をはじめ各SIerとタイアップした技術サポート体制で安定した立ち上げを果たした。 その結果、A製鉄所では生産計画からはじまった一連のマイグレーションにより、3台あったメインフレームを1台に削減することに成功した。残る操業オインライン機能についても、ここで確立したオープン系技術による新操業オンライン基盤を順次上位工程に展開し、最終的にはメインフレームレスを目指す予定である（図2）。  図2:A製鉄所のシステム構成図 （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||||
| 今回のまとめ 〜 全体最適化を目指した設計と移行ロードマップの必要性 | ||||||||||||||
|
ここまでが当社におけるメインフレーム資産の移行事例の概要である。数年がかりの遠大な計画に基づく、まさしく鉄鋼業界に相応しい重厚長大なマイグレーションという印象を与えたかもしれない。 しかし、現状の整理と全体最適モデルの策定、その全体最適モデルに基づいての移行ロードマップ、それらを実現する技術や開発手法などの標準化といった努力の上にこそ、システムの俊敏性とコスト削減の実現が可能となることもまた事実である。 ここを軽視して単に安価なオープン系基盤へ移行するという姿勢で取り組んでも、コスト削減はおろか、運用保守局面で品質低下・保守費用の増大を呼びかねない。それゆえに、今回はあえて王道的アプローチ事例を紹介した理由である。 次回は、レガシーすなわちメインフレームではない事例として、多くの企業で使われているVisual Basicで作られたクライアントサーバ／システムのマイグレーション事例を取り上げる予定だ。 |
||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
