SOX対応ソリューションの要と期待されるBPM(Business Process Management) (3) 

徳田浩司(Koji Tokuda) 2006-07-29 06:41:52

前回「SOX対応ソリューションの要と期待されるBPM (2)」では、BPMSuite(Business Process Management Suite)の機能について、1.Workflow(Business Process)、2.Business Rules、3.Enterprise Application Integration(EAI)、4.Business To Business Integration について述べた。引き続き残りの機能について見てみたい。

5.Business Process Monitoring & Analytics

企業全体に業務プロセス(ワークフロー)が存在するわけであるが、各組織、そして個人にも存在する。BPMを使うと、組織図にあわせて、ポジション毎に機能、役割分担、権限と責任が明確化される。業務分掌とビジネスプロセス及びシステムをドッキングすることができる。

個人の活動は、上位者及び管理部門によって監視され、異例操作はアラートが出され、権限を超える操作を禁じる。また、個人個人の活動が記録されることで、業務の繁忙、個人間での分担の偏り(というよりも仕事をしていないのが誰かわかる)、パフォーマンスが、明らかになる。管理が厳しくなるのは嫌なものだが、効率化を上げるためには必要である。BPMのモニタリングと分析機能を活用することにより、業務プロセスや業務分担など問題あるところが見えてくる。BPMを用いれば、環境の変化に合わせて、システムの変更もスピーディーな対応が可能となる。それまで、本部からの全社画一的なお仕着せのシステム提供だったのが、BPM導入後は、現場からの意見を取り入れながら、実態に合わせて部門毎にきめ細かく対応することが可能となる。更に、今のビジネスで、システムが十分対応できているか、無駄は無いか、不足するものは無いか、ということも明らかになる。

BPMは導入後が重要で、ここまでルーティン化できれば、BPM導入のメリットが目に見えて出てくる。

6.Solution Frameworks

最後に、BPMSuite全体のフレームワークが重要となる。これは、BPMを中心とした社内システムの拡張である。新規のビジネス参入や新しい業務が出てくるたびに、業種別の業務システムを継ぎ足していくときの、接続方法である。SOA技術を用いた基盤が出来上がっていると、拡張とリンクがしやすくなる。既存のインフラを活用することができるため、開発コストも大幅に下げることが可能となる。

特に金融やオンラインビジネスなど、業界を超えて業務が拡大している。また、合併によりシステムの統合が必要となるケースも増えている。BPMを用いた基盤があれば、産業毎に必要な業種別アプリケーションを継ぎ足すだけで、新規にビジネスを行うことが可能となる。ゼロから立ち上げるよりもはるかに早いはずだ。米国では、成功事例がたくさん出てきている。

日本でのBPM導入は可能か?

もちろん、これまでの話はSOA基盤としたシステムのインフラが出来上がっているという前提で、米国での話である。SOAは儲からない、言っているほど上手くいかない、という話がつい最近まであったが、ここに来て、効果が出ている、導入が進んでいるというレポートが出てきている。ZDNetSOAブログでも「SOAの導入で年間5%のコスト削減が可能に――最新調査」「SOAの利用事例数が2005年と比べて2倍に――最新調査結果」などの記事がある。導入のドライビングフォースとなったのは、SOXやHIPPAなどコンプライアンス対応である。日本においては、業務システムは自社開発の独自のシステムでできあがっていることが少なくない。米国と違って日本では人員の流動化が少ないので、同じシステム部員が長く担当していることから、開発のノウハウなどがきちんと文書化されていないものが少なくなく、人が異動したりやめれば必要な情報が散逸し、あとからシステムに手を加えることが簡単に出来ないのかもしれない。BPM導入が可能となるためのSOAのインフラを作り上げるまでには大きな苦しみが伴うだろう。

私も思い当たるような経験がある。銀行の子会社にいたときに、オフィスを移転することになり、経営企画部門にいた私が引越し業務の統括責任者となった。移転に合わせて、社内システムも再構築することになり、銀行に接続しているネットワークの移転とか社内システムの見直しも私が担当することになった。投資先企業を管理するシステムも手直しすることになったが、そのシステムは、MS-ACEESSをベースで開発したもので、そんなに複雑なものではなかった。画面のトップページに、一社ごと、企業名、投資金額、投資時期、売上、利益、業務内容など、概略を表示しているものであった。トップから、一覧で見るにはいくつか追加したい情報があって、2、3新しく情報項目を増やして欲しい、という要請があった。最初は、表示方法を手直しするだけなので、それほど大変な話だとは思っていなかった。ところが、最初に開発を依頼したSIの担当者は既にいなくなっており、更に、ドキュメントも残っていなかったので、どのように手をつければよいかわからず、お手上げ状態であった。そこで別のSIに修正をお願いすることになった。全体の構造を一からドキュメント化することとなり、結局3ヶ月ぐらい時間がかかった。もちろん、高額の手数料を支払う羽目となった。非常に分厚いドキュメントができたが、2,3の修正のためにそこまで必要だというのをなかなか上に説明できず、当時はかなり高いと思った。しかし、若しそのときBPMがあったとしたら、私の手元で簡単に修正できていたはずで、更なる変更も簡単に出来るので、コストは限りなくゼロに近づいたはずだ。

BPMの導入によるコストダウン

BPMを用いて業務フローとシステムを可視化しSOA対応に移行することは、自社開発とカスタマイズを繰り返してきた日本企業にとって大変な困難が伴うと思われる。それならば、その都度カスタマイズで対応するか、ゼロから作り直した方が早いという意見もある。確かに、短期的にはその方が有利である。しかし、ユーザの立場からすると、一度、社内のシステムがどの業務とリンクしているのか明確にしておくことは、システムにブラックボックスがなくなるわけで、SIに対する大きな牽制力となる。要るのか要らないのかわからない機能がふんだんに盛り込まれたソリューションに対して、一括でいくらですといわれて、高いお金を払う必要がなくなるわけである。また、システムを機能ごとに切り刻むことで、モジュール化が可能となるので、今後SOA対応のアドオンのツールがどんどん出てきた時に、不足する機能だけを、必要になったときに必要なだけ採用することが可能となる。そのため、無駄な投資が不要になり、メンテナンスコストを減らす効果が出てくる。また、人材の流動化もどんどん進んでいくことから、これまでのように自社開発だけに頼るのは限界があり、BPMによる標準化は重要である。企業や業種を超えて、BPMを標準化しようとする動きが出ており、その標準に準拠した基盤を作り上げることで、必要最小限の機能に絞り込まれたパッケージを低価格で活用することが可能となる。

SOX対応を錦の御旗にBPM導入、SOA対応を進めるべき

新しいことをやろうとすると、最初はお金がかかる。だから簡単には先に進まない。

SOX対応も後ろ向きな話と捉えられている。元々は、エンロン、ワールドコムに始まって、ライブドアなど上場企業の粉飾事件がきっかけとなったもので、一般投資家をだます悪者を締め出し、抑制するものである。一部の不心得者のために、大多数のまじめな会社にとっては不要なコストが強要され、何億円もお金をかけるなんて本当にばかばかしいものだ。数億円のコスト負担が、何十億円もの企業価値を下げることになるので、それだけのためであれば、SOX対応なんてとっととやめるべきと思う。

しかし、ルールはルールで決まったものは従わなければならない。だったら、どうせお金をかけるならば、継続して効果の現れるような投資を行うべきだろう。責任を逃れをするために、監査を通すことだけを考えて、業務フローの文書化を手がけ、ドキュメント作りだけでおしまい、というのでは本当にもったいない。米国でも、最初はドキュメント化だけで終わっているケースは少なくなかったが、今年に入って、IT化を進めて自動化に結びつけ、SOX対応のコストを下げようとする動きが出ている。

BPMのようなシステムは、現場は必要だと思っていても、なかなかトップは理解してくれないかもしれない。無かったら日常業務に支障が出るようなシステムでないがゆえに、トップも、お金をかけてまで整備しようという気にはならないのだと思う。しかし、J-SOX対応のためには必要だという話になれば別で、経営会議は通りやすいだろうし、投資家も説得できるだろう。

J-SOX対応で、ITが必要だという風潮を非難する声がある。もちろん必要ないものを投資すべきではない。しかし、むしろ逆で、必要なものは積極的に投資しておくべきだと思う。

SOX対応によるIT化のブームをテイクチャンスして、錦の御旗として、社内稟議を通してしまうべきである。将来のために社内のシステムを高度化し、リスク軽減とコスト削減、ビジネス変化への対応力を向上させることを考えるべきではないだろうか。更に、不要なスペックを提示して高い開発費をふっかけてきたSI企業に、今後だまされないようにするためにも、導入を検討する意味は十分あると思うがどうだろうか?

(SI企業は、SOAとかBPMはコストがかかるし、手間隙かかって上手くいかないので止めたほうがよい、と言うかもしれない。そのほうが、いつまでも、社内外に大量に抱えるプログラマーを食わすことの出来る、人月のかかる開発プロジェクトが受注できるからである。ツールベンダー以外は、興味ない話かもしれない。業界の方々ごめんなさい。でも私が言わんとすることが理解でき、提案力と技術力のあるシステムコンティング会社には、プラスになる話だと思う。)

(徳田浩司 koji.tokuda at www.fusion-reactor.biz

※このエントリはZDNetブロガーにより投稿されたものです。朝日インタラクティブ および ZDNet編集部の見解・意向を示すものではありません。

SpecialPR