IT部門は社内コンサルタントとしてビジネスプロセスの全体最適を実現せよ

ソニー出井さんのグループCEO 退任が発表されてしまいましたね。TR60はどうなるのでしょうか。散り際を乱すより、今勇退したほうが得策と考えたのか….今後の展開に期待しています。
さて、前回は、SAPのBusiness Process Platformを題材として取り上げましたが、実際にどのようにしてビジネスプロセスを構築して行くか、その方法をこれから数回に渡って、考えます。
ERP の導入は、どういう意味があるでしょうか。


それは、ビジネスプロセスの最適化という意味があります。
今までばらばらだった会計システムとか受注システムというような個別の業務システムを、ERP によって統合しようというこの試みは、業務の効率化という点では、確かに一定の成果を収めてきました。
しかしながら、現実には、全社的なビジネスプロセスが統合されている企業は、ほとんどありません。
理由は?
ERP システムだけで、すべての企業情報システムが完結するわけではないからです。ERPだけで、業務システムを構築している企業は、皆無です。
仮に、ERP システムを導入しても、分析系、企業間連携、フロント系、業種特化型などのアプリケーションが必ずその外に残ります。
しかも、次々に新たなビジネスニーズが生まれてきます。その動きに対応するために、ERP の外側に新たなシステムが日々追加されることになります。当然ながら、ビジネスプロセスも、ERPシステムの外に形成されることになります。
SAP で考えても、BW (Business Information Warehouse)、CRM、SCM、EBP …といったシステムがERPの外側に開発され、ERPとともに、Business Suiteとして販売されています。
ビジネスプロセスの統合という課題に対してERP システムが限界を抱えていることは、ERPによる基幹系システムの全面統合を声高に訴えていたSAPがBusiness
Process Platformのように、他システムとの連携を強調するようになっていることを見ても明らかです。
また、ERP システムが包含しているとされる「ベストプラクティス」の有効性についても、ビジネスプロセスの最適化という観点から見れば、はなはだ疑問な点もあります。
ERP パッケージは、それぞれの業界に適合し、全社的に最適化され洗練された業務とデータのモデルが出来上がっています。そのために、導入時には、ユーザーが自社固有の業務のやり方を改め、「システムに業務を合わせる」必要がでてきます。
自社固有のビジネスプロセスを維持することは、カスタマイズによるコスト増を生み、アプリケーションの保守やバージョンアップの妨げとなることから、むしろ「悪の代名詞」と見なされて来ました。
しかし、パッケージ製品が、すべての企業に適合するベストプラクティスを提供できていたかと言えば、必ずしもそうとは言い切れません。以前にも言いましたように、複数の企業で採用されているビジネスプロセスを提供しているのです。
現に、ERP を導入したユーザーの経営者や、現場の業務担当者の間からは、「日本企業ならではの、あるいは自社固有の強みや、他社との差別化を図るうえでのポイントとなってきたビジネスプロセスが、ERP システムによって打ち消されてしまったのではないか」といった疑問の声も聞かれることもあります。
以前に紹介したソニーは、この点を非常に意識して導入をしています。生産系はxxxを、販売系はyyyを、物流系はzzzを、というようにグローバルにシステムの標準化をして、自社の優位性を発揮できる分野は、手作りでシステムを構築しています。(xyzのところは、固有名詞を書けないのでご了解ください。)
SAPを導入した際も、自社の優位と考えられるプロセスはアドオンを開発し、SAP の機能をエンジンとして使用する方針の下、プロジェクトが実施されました。
ビジネスプロセスは、自社がどのように顧客に価値を提供するかを端的に物語るものであり、企業にとっては最も重要なノウハウでありナレッジであると言っても過言ではないと思います。
従って、たとえERPを導入したとしても、それを1つのプロセスコンポーネントととらえ、今後は、独自の強みを発揮できるビジネスプロセスは別途自らの手でデザインすることが求められるのではないでしょうか。
そんなことを行ったら、今までもそうですが、インターフェースのお化けがさらに、巨大になって、運用コストが増大するのではないかと、反対される意見が聞こえてきます。
そこに、SAP がいうNetWeaverやBusiness Process Platformの意味があるのです。SAP 以外を使用しても、EAIやWeb Serviceを使用して社内システム構築の標準化をすれば、同じことなのです。
では、実際には、どのようにしてビジネスプロセスをデザインすれば良いでしょうか。
ビジネスプロセスは通常、事業部門の担当者が実行するものです。従って、これまではその「デザイン」についても、当然のように事業部門が主体となって行ってきました。
しかし、今やビジネスプロセスのほとんどが情報システムによって支えられています。
しかも、ビジネスシステムの重要な要素であり、ビジネスプロセスのインプットおよびアウトプットとなる「データ」は、情報システムによって構築されたデータベース内に保管されていいます。
さらに、分析や参照といった、当該ビジネスプロセス以外の目的にも用いられるようになってきています。
こうしたことから考えても、一事業部門の視点のみで、ビジネスプロセスをデザインしたり、そのバックエンドで稼働する情報システムやデータベースを規定したりすることが、もはや時代にそぐわなくなってきたことは確かです。
今、ビジネスプロセスのデザインに求められているのは、部分最適ではなく、部門横断的な視点に基づいた全体最適の視点なのです。
と言っても、一般に事業部門の担当者は、自分または自部門が実行するプロセスについては熟知していても、他部門のプロセスや全社的なビジネスプロセスを実行するために必要となるデータについては十分に把握していないことがままあります。
ここにおいて(ITによって)日ごろから全社的な視点で業務の最適化に取り組んでいるCIOならびにIT部門の関与が求められることになります。
ただし、関与と言っても、求められるのは、従来のように事業部門が現行業務をベースとしてシステム化要件を定義し、IT部門がその要件に従って(または、それぞれのニーズを鵜呑みにして)システムを構築する、といった受動的な関与ではありません。
それは、全社の情報システムを知り尽くしたITスタッフが、いわば「社内コンサルタント」となってあるべきビジネスプロセスをモデル化し、必要に応じて現行のプロセスに変革を促していくような、能動的な関与です。
ただ、これは、言うは易し、行い難し….と非常にタフな課題なのは事実です。
企業におけるIT部門の存在理由を考えれば、「要件に基づいてシステムを開発し、運用する」という役割だけにとどまっていたのでは、外部のITベンダーと何ら変わりがありません。
グループ経営、グローバル化、競争激化といった昨今の経営環境の中にあって、IT部門が存在価値を高めていくためには、ビジネス・プロセスの領域に積極的に足を踏み込んでいくことが必要ではないでしょうか。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*