さて、これまではWhat を考えてきましたが、ここからはHowについて検討していきましょう。ビジネスの貢献する仕組みと仕掛け、すなわちプロセスの構造とか機能をどんなものにするのかから、それをどうやって設計し、実装していくかという問題です。

そこで重要なコンセプトを思い出してください。「Function/Data Oriented」「Development Excellence」「Independent Work」から「Process Oriented」「Operation Excellence」「Collaborative Work」にシフトしましょうということを提案しました。この新しいコンセプトに沿ったHowを考えて行きます。ただ、「Development Excellence」から「Operation Excellence」だから、開発はあまり重要ではないと思わないでください。重点が移動したのであって、まだその重要性は変わりません。

Howの最初はプロセス設計になりますが、そこで大事なのは「プロセス中心アプローチ」という考え方を理解することです。設計ではプロセス中心というよりもプロセス先行といった方がわかりやすいと思います。言葉のとおり、まずプロセスを作っておいてそこにそれ以外の要素を定義していくというやり方です。

こういうことを言うとそれはデータ中心でやるべきだとかという声が聞こえてきます。なるほどDOA(Data Oriented Approach)ですね。以前にも何回かこのブログでも言及しましたが、プロセス中心かデータ中心のどっちを取るのかという議論ではなく、向き不向きがあるので使い分けることが大切です。

つまり、データでマスタのようなリソース系のデータ(名詞形で表現できる)はデータ中心でやるべきです。リソース系というのは、企業活動の原動力になるわけですから、個々のプロセスには関係なく前もって決めておくものです。例えば、従業員データとか取引先マスタといったものは、それがビジネスを動かすためにあるというか、手持ちのリソースを使ってどんなビジネスをするのかが決まったりします。しかも全社に渡って使われるものですから、あらかじめデータベースを設計しておくことをします。

一方、トランザクションから発生するようなイベント系のデータ(動詞形で表現できる)は、プロセス中心でやるべきであると主張しています。イベントデータはプロセスがあってこそ存在するわけですから、まずは企業活動の一部としてどんなプロセスがあって、そこで生成するデータは何かというアプローチになるわけです。

例えば、受注データというイベントデータは、受注プロセスから出てきますし、売上データも同じように販売プロセスと対になっています。取引先データは購買プロセスから出てきませんよね。ですから、理想的にはプロセスを正規化しておけばイベントデータも正規化されることになります。このことは業務の標準化や共通化という視点からも重要なことだと思います。

ということで、データ中心ではプロセス設計はかなり難しくなりますので、プロセス先行設計を勧めています。まず最初に業務の流れを中心としたプロセスを描き、そこに必要なデータは何か、使うユーザインターフェースはどんなものにするのか、どんな業務ルールに従うのか、責任の所在はどこにあるのか、何を測定してコントロールするのかといったことを設計、定義していくのです。

このやり方は、実はユーザの人たちにとってもなじみやすいこともあります。なぜならば、業務の流れとか、仕事の段取りといったようなことって結局プロセスだよねということです。データフロー図(DFD)を追っても、ER図をながめてもユーザの人はなかなか理解できないのではないでしょうか。
 

No TrackBacks

TrackBack URL: http://blog.wadit.jp/mt/mt-tb.cgi/44

Leave a comment

About this Entry

This page contains a single entry by Masanori Wada published on April 16, 2012 9:58 AM.

コンサルティングの成果が紹介されました was the previous entry in this blog.

非定型業務のIT化 - 業務プロセス設計が肝 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Pages

Powered by Movable Type 4.34-en