このように多様な業務と多様な業務を電子化したシステムがありますが、業務面においてもシステム面においても全体最適のキーワードは標準化です。業務を標準化するということは、業務を特定のルールや記述方法など統一した方法で規定し表現するということです。表現したい業務についてちゃんと理解しているか?ということがポイントになってきます。現業務としてなんとなくこのデータを入力しているけど、この入力されたデータはどんな処理がされて何に活かされているのかがわからないなんてことは多いのです。アシスタントや若手社員が実際の業務を担当して様々なデータを入力しているがその意味や背景はわからない。逆に上長や経験が長い人はその業務の意味や本質は理解していても詳細なデータについては知らないということがあります。「業務手順や業務内容を明確にすること」が標準化への初めの第一歩です。業務手順や業務内容を明確にするためには2つの方法があります。(a)現状業務の手順や内容を明確にするアプローチ(b)あるべき業務の手順や内容を明確にするアプローチの2つです。(a)の業務を明確にした後に行う作業は業務の改善です。ある意味では、現業務を改善するために現業務を明確にするのです。マイケル・ハマー氏のビジネス・プロセス・リエンジニアリング(BPR)は業務の流れを分析して最適化する手法ですが、業務を再構築(リエンジニアリング)することはビジネスモデルやビジネスシステムなどにも影響して大きく業務を変えることになりかねませんので容易ではありません。現業務の改善が最適な解だと言えます。(b)のアプローチはゼロからあるべき業務を作り上げるアプローチです。現業務のことを理解しながらも、現業務の問題点やシステムの制約などを気にせずに純粋に今の業務をより簡単に効率よく行うためにどのような手順や内容にすればいいのかを検討するのである意味では自由で簡単かもしれません。今現在も業務は動いているので(a)のアプローチを取ることが多いのですが、(b)のアプローチをとることを選択肢から外さないことが重要です。コンピュータシステムアーキテクチャとしてクライアント・サーバ方式からWeb方式に変わるタイミング、クラウドコンピューティングに変更するタイミングなどで(b)のアプローチを利用して業務最適化をすることが必要です。システム面での標準化システム面での標準化は様々なレベルで考えられます。米国国防総省に端を発するエンタープライズアーキテクチャ(EA)は、大企業や公共機関などの大きな組織の業務手順や情報システムの標準化、組織の最適化を進め、効率よい組織の運営を図るための方法論です。EAを使ってシステム面の何を標準化するといえば技術、アプリケーション、データのアーキテクチャです。技術アーキテクチャは一番下層部にあるアーキテクチャで技術アーキテクチャを決めることはその上のアプリケーションやデータのアーキテクチャを決定づけるため非常に重要です。技術アーキテクチャはシステムを安定的に構築・運用・拡張するために必要なIT基盤を定義して技術標準を定めたものです。この技術標準を決めれば今後の採用技術を一定に保つことができ全体最適に繋がります。アプリケーションアーキテクチャは技術アーキテクチャの上に位置します。アプリケーションアーキテクチャは業務プロセスを実装する機能要件の定義方法の標準化です。これにより新しい業務が出てきたとしてもその実装方法が自ずと決まってきます。データアーキテクチャはアプリケーションアーキテクチャの上に位置します。データアーキテクチャはデータについて定義したものです。データの定義とはデータのもつ意味、データの発生ポイント、保有方法、データ消去、データ品質などを定義することです。これにより新しい業務が出てきたとしてもどのようなデータにすべきかが自ずと決まってきてアプリケーションやシステムが安定してきます。全体最適をするにはEAが有効ですが、全体最適で注意しなければならないのは全体最適の最適解を固定しないことです。固定しないと不安定になりまた全体最適が崩れてしまうリスクがでてきます。全体最適における標準化と柔軟性はトレードオフになります。何が企業や公共団体にとってトレードオフにならない絶対的な存在なのでしょうか?それは“データ“です。次回はデータについて考えてみます。Reader®が必要です。