アカウント名:
パスワード:
「初期コストは従来程度」としながらも「中長期的にはドラスティックなコスト削減が可能」と述べ、メインフレームを使った従来の基幹系システムと比較して、運用管理コストを大きく削減できることをアピールした。
まあ１０年後ぐらいになると、運用ノウハウをもった人材集めるだけで骨折るようになり、ハードにがたがき始めたらもう手に負えなくなると思うけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
日経コンピュータでも (スコア:1)
日本ユニシスはホクホク顔ですが、日立は泣き顔ですね。
Super Souya
Re:日経コンピュータでも (スコア:3, 参考になる)
http://www.atmarkit.co.jp/news/200312/03/bank.html [atmarkit.co.jp] 素人の憶測だけど日立よりユニシスのほうが儲けありそう
Re:日経コンピュータでも (スコア:0)
意味ないジャン、Windowsでこの手のものを作るのも今ならありえる話だとは思うけど、どう考えても４、５年で全面リプレースが前提だと思うけど、この手のところって２０年ぐらい使い続けるでしょ。
まあ１０年後ぐらいになる
Re:日経コンピュータでも (スコア:5, 参考になる)
>意味ないジャン
いや、かなり意義があると思いますよ
通常、普通銀行のシステム投資額は、大雑把な指数として預金総額の0.1%、つまり百五銀行の場合だと預金総額が平成15年9月期で3兆2000億円ですから、システム投資額は毎年30億円前後くらいしかかけられないわけです
都銀(下位都銀だが)と(百五のような中位)地銀は単純比較はできませんが、りそな銀行の勘定系統合が従来計画の旧あさひ(CAP)を旧大和(NEWTON)に統合する計画を取りやめ、NEWTONをCAPに統合することで統合費用を大幅に削減する新計画を立てましたが、この場合の想定費用が320億程度と預金額(りそな銀単体で21兆、埼玉りそな銀と合算で30兆)の0.1%におおむね収まる程度なのです。それを考えると、従来コストで基幹系を刷新するというのは結構ポイントが高いのではないかと
>運用ノウハウをもった人材集めるだけで骨折るようになり
ここなんですが、従来のメインフレームベースの勘定系だと20年近く前に構築されたシステムをベースにしているわけで、速度を稼ぐ為にアセンブラで書いたコードが大量にあったり、下手すると(実際に九州地方の某UNISYSユーザーがそうだけど)OS自体を自行専用に開発してしまっている銀行もあったりします
こういったことが可能だったのは、従来の勘定系業務がここ20年ほど大きな変化がなかったためで、極端に言えば午前9時から午後3時までの法定営業時間のオンライン業務と、それ以外の時間帯で走らせる各種バッチ業務ができればそれでよく、預金勘定もそう大きな変化がなかったために、銀行のシステム子会社とメーカーからの応援人員だけで何とか対応できてたわけです
ところが、子会社に抱えてる開発要員の中堅層が大量に退職する2007年前後に深刻な人員不足を来たすと予想されるいわゆる2007年問題や、メインフレーマーのメインフレームサポートの縮小などで、従来一定に収まっていた運用コストは増大が予想されますし、金融ニーズの変化に対応するためには、これまでのようにオンラインとオフラインのトランザクションを交互に切り替えることができなくなってきています
後者に関しては、外から見てわかりやすい例だと、インターネット・バンキングやデビットカード、キャッシュサービスの24時間対応ができない例などですが、昨年11月に稼動した第5次全銀システムや今年1月に稼動したt統合キャッシュサービスネットワーク [srad.jp]、マルチペイメントネットワーク [jammo.org]の本格稼動など、勘定業務が24時間稼動していないと困るような状況が地方銀行にも波及してきているのです
そうなると、a)従来の勘定系を無理やり維持する、ということは不可能に近いわけで、b)従来のシステムをゆるやかに解体しながら新しいシステムに切り替えていく、c)先進的なシステムをベースに共同化する、d)パッケージを使って刷新する、という三つの選択肢が考えられると思います。(これについては過去 [srad.jp]にちょろっと書きましたが)
b)に関しては、メガバンクが取っている方向性で勘定系中心の第三次オンラインシステム的なシステム構成(言ってみればスター型)を、EAIツールを使ったハブシステムを中心とするハブ型に再構成するというものですが、巨額の費用がかかるために地銀では現実的ではありません
c)に関しては、タレコミ分でも触れたNTTデータの勘定系パッケージBeSTA(これ自体は今月キックオフカスタマーの京都銀行が本番運用に入っています)を使ったものや、日立製作所、東京三菱銀行と地銀連合、IBMなど既存システムをベースに参加行がシェアして運用を共同化する共同化システム方式で、すでに稼動しているものも多いです。この方式は、リスクは低いのですが長期的にはアウトソーサーに一定の「利用料金」を支払う感じになりますし、言ってみれば「既製服に体を合わせる」形になるので、場合によっては全体でかかるコストが増大する可能性もあります
d)の場合は、出来合いのパッケージを使って再構成するわけですから、共同化よりも自由度が高く初期投資はかかりますが、後は減価償却していくだけなので長期的には安いでしょう。BeSTAのほかにも、NECのBankingWeb21(八千代銀行で昨年稼動、百五銀と同じ三重県の三重銀行がUNIXベースのBW21を採用予定)、富士通のProbank(東邦銀行で昨年稼動)、タレコミ文でも挙げたFLEXCUBEなどがそうです。BW21やProbankは開発体制の構築や標準化に手間取っていますが、NTTデータやUNISYSは従来からメインフレームベースの勘定系パッケージを提供している経験があるのである程度安心できるのではないかと
>どうするつもりなんだろう？
この点に関しては、タレコミ文に
Re:日経コンピュータでも (スコア:0)
Re:日経コンピュータでも (スコア:0)
目先のコスト削減で手一杯なんじゃないかな。
IBM pSeriesにLinux載っける方がTCO削減できると思うが。
Re:日経コンピュータでも (スコア:1)
その何かの理由も考慮に入れて、問題ないと判断できるかが
大切ですよねー。
システムに限らず、ですけど。
Re:日経コンピュータでも (スコア:0)
> どうするつもりなんだろう？
普通に保守契約するだけだと思いますが。
Re:日経コンピュータでも (スコア:0)
とってもメインフレーム的発想ですね
Re:日経コンピュータでも (スコア:0)
そうかなあ。
10年経ったら保守用のハードウェアは多分入手できなくなってると思うし、代替ハードウェアを利用するためには結局再開発が必要になってコストがかさむんじゃないの？
あと、Windows技術者を数多く集めるだけなら苦労しないけど、使える奴を集める
Re:日経コンピュータでも (スコア:0)
＃え、何が無くなってるかって？
無くなるもの (スコア:0)
そりゃ決まっているでしょ。日本国と政治家
アメリカ合衆国ジパング州になりますから。
そのうち、銀行のシステムがラックマウントサーバに
収まるようになったら、イヤだな。
Re:無くなるもの (スコア:0)
>収まるようになったら、イヤだな。
でも、少なくとも現行の規模のシステムくらいならラックマウントサーバどころか手のひらに乗るくらいのサ
Re:無くなるもの (スコア:0)