IT戦略策定の最近のブログ記事

システム構成に関して異なるポイントを紹介します。ローカル要件としたものをどのように扱うかと言うポイントです。

ERP、特にSAP R/3を複数拠点に導入する場合は、システム構成を慎重に検討しなければなりません。

ローカル要件が、標準機能で対応できる場合、既存のアプリケーションを使用する場合は、あまり問題にはなりません。問題となるのは、アドオンを開発して対応するという方針を立てた場合です。

導入戦略の中のシステム構成をどのように考えるかを検討します。

システム構成とは、導入しようとするパッケージ、或いは、開発するアプリケーションをどのような環境で実現するのか？メインフレームで実現するのか、クライアントサーバーで実現するのか？

という課題が必ず浮上します。

SAP R/3を例に取れば、メインフレームにも、クライアントサーバーにも対応していますが、特に、私が経験したプロジェクトでは、クライアントサーバーで実現しながら、種々問題点を抱えたものが少なくありませんでした。

前回紹介したGMの海外展開方法ですが、現在では、かなり、修正が加えられ、EAを元に、共通システムの構築を目指しているようです。企業として目指しているのは、「動きの鈍い”巨大企業から、タイムリーな意思決定が行える“柔軟で機敏な”企業への転身」だそうです。

各国ばらばらに導入したSAP R/3をどの様に扱うのか、その結果を早く見たいものです。

さて、前回の続きで、導入対象範囲に関して考えていきます。

どのレベルまで標準化するかということを考えましたが、海外展開の場合は、いろいろな要素が追加されます。

情報化企画において、業務分析とシステム要件を見てきました。次に考えるポイントは、具体的なパッケージの導入戦略です。ERP、特にSAP R/3導入の体験を下に、ポイントを整理します。

この段階で考えなければならない導入戦略は、

1. 導入対象範囲
　　1-1. スコープ
　　1-2. 導入順序
　　1-3. 標準化すべき業務プロセス
　　1-4. 部門間、会社間の情報、プロセスフロー
　　1-5. 組織構造のモデリング
2. システム構成
　　2-1. システム構成
　　2-2. ネットワーク
　　2-3. 分散アプリケーション環境

今回は、これらの内、導入対象範囲を考えます。

全社的なアプリケーション統合基盤を導入することによって、実際にどのようなメリットを享受することができるのでしょうか。

まず、企業経営の側面からのメリットを挙げると、システムのコンポーネント化が容易になるため、部門ごとの業務に応じて適切なコンポーネントを選択することが可能となります。

さらに、業務環境の変化により素早く対応できるようになります。

アプリケーション統合に押し寄せるWebサービスに関して見ることにします。

最近では、企業内のアプリケーション統合にとどまらず、企業間での高度なアプリケーション連携が現実のものになりつつあります。

これまで、企業間の連携と言えば、EDI (Electronic Data Intercha nge)によるデータ連携のことを意味していました。

先週のメルマガに関し、読者の方から、マスターとマスタが混在しているとの指摘がありました。内容的にはメルマガの内容とは関係ないのですがと前置きされながら。

鋭い指摘だと思いながら、SAP R/3の翻訳もコンサルタントが行っていた初期のころを思い出してしまいました。単語の最後のーを省略するのは、翻訳の試行錯誤の結果なのです。

アプリケーションは、どのようにして統合すればよいのでしょうか。

企業内にある複数のシステムを統合するにあたって、最初に考慮しなければならないのは、接続形態です。一般的には、次の4つの接続形態があります。

情報化企画の上で重要である、業務分析とBPM (Business Process Management)の動向を見てきました。すなわち、新ビジネスプロセスが定義され、それを実現するための新技術動向を把握しました。次に必要なことは、どの技術を使用して実現するかを決定することです。

パッケージを使用しても、手作りで開発しても、それを闇雲に導入して行くと言うわけには行きません。業務の全体最適化を考慮したわけですから、今度は、システムの全体最適化を計らなければなりません。

そこで、今月は、システムの全体最適化を考えるため、アプリケーションの統合に関して見て行きたいと思います。

今回は、デザインしたビジネスプロセスをどのようにしてシステムに落とし込むかを考えます。

まずは、その変遷。

実際のビジネスを情報システムに投影しようとする取り組みには、1970年代に提唱され、データベース設計などの際には現在でも利用されているER（Entity Relationship）モデルをはじめ、データフロー図（DFD）、オブジェクト・モデリングなど、さまざまな手法が開発されてきました。

今回は、具体的にどのようにして、ビジネスプロセスを組み立てるかを考えます。

ビジネスプロセスをデザインする際の作業の進め方には、大きく分けて２とおりのアプローチがあります。

１つは、現行のプロセスを分析し、その改善策を練っていくというもの。
もう１つはあるべきプロセスを一から描くというものです。

ソニー出井さんのグループCEO 退任が発表されてしまいましたね。TR60はどうなるのでしょうか。散り際を乱すより、今勇退したほうが得策と考えたのか....今後の展開に期待しています。

さて、前回は、SAPのBusiness Process Platformを題材として取り上げましたが、実際にどのようにしてビジネスプロセスを構築して行くか、その方法をこれから数回に渡って、考えます。

ERP の導入は、どういう意味があるでしょうか。

情報化企画には、将来のITに対する必要条件をまとめなければなりません。そのためには、新技術の動向を把握し、情報を集めなければならないのは、言うまでもありません。

先週のビジネスプロセスに関する関連した新技術の発表がありましたので、今回は、それをベースに考察します。

その新技術とは、

今回より、情報化企画の段階で、非常に重要な業務分析を考えます。
これは、ERP に限らず、採用する情報化ソリューションに必要な業務を、どのように改善すれば良いかを試行することです。

システム導入には、業務改善が不可欠だという話がよくあります。業務改善は、システム導入前にするべきなのでしょうか。それとも、後にするべきなのでしょうか。

今回から、戦略情報化企画の話題に移ります。経営戦略策定では、今後の方向性を決定しましたが、その中で、ITを使えばより効果的に目標を達成することができる項目を抽出しました。

戦略情報化企画でも、経営戦略策定と同じ方法を取ります。現状の情報システムを分析し、あるべき姿をシステム目標として設定し、そのシステム的な評価指標を設定します。