前回、プロセス参照モデルからレベル4までの分解を行いました。具体例でいうと受注生産品の見積提示プロセスの引合見積プロセスを見積依頼の受領・確認―見積条件の検討(与信)―見積条件の検討(プロダクト・価格)―見積条件の検討(納入条件)―見積回答の作成―見積回答の送付というふうに分解しました。

更にその中身を見ていくと、例えば前回も例にしましたが、見積条件の検討(プロダクト・価格)というプロセスがあります。そこのプロセス定義をどうするかというと、プロセス名、目的・機能、インプットデータ、アウトプットデータ、ルール、パフォーマンス、担当責任といったところを記述します。インプットデータは指示情報とか参照情報で、アウトプットデータはプロセスの成果物になります。例で言うと、要求仕様や製品カタログ、価格表、原価、見積履歴などがインプットで、商品番号や見積価格がアウトプットになります。

さてこうした定義がされたあと、どう実装するのかを見ていきます。というとこのレベルで実装するのかという質問が飛んできそうです。おいおい分かってきますが、このレベルで実装してしまうというのがポイントになってきます。これを従来のやり方だとどうなるのでしょうか。従来のやり方というとスクラッチでコードを書く、パッケージを持ってくる、フレームワークをカスタマイズする、クラウドを利用するなんてことになるかもしれません。   

これでできるでしょうか。見積書に記載するプロダクトとその価格を決めるプロセスをコードで書くのか、パッケージを持ってくるのかですが、実は従来の開発ではここのところは無視されています。どういうことかと言うと、プロダクトと価格が決まったあとにその情報を登録する画面を開発することが行われていたということです。

レベル4のプロセスをそのまま実装したいという意味は、登録するデータを決めるまでが大変重要でそこをITを活用して効率的に質の高い決定を行いたいからです。このあたりはもうすでに書いてきたなので繰り返しませんが、せっかくプロセス記述でビジネス要求を埋め込んであるのでそれが反映できるようにしたいのです。単に、データを登録するだけだとビジネス要求がどこかへ行ってしまいます。

世の中に多くの見積システムというのが提示されています。SFAとかCRMの中にも入っていたり、クラウドでも提供されています。しかしながら、このシステムの構造をよくみていただきたいのですが、ほとんどが「見積書作成・承認プロセス」です。見積書のフォームが出てきて、そこに必要なデータを登録して、それを上長が承認し、プリントアウトするという仕組みだと思います。

くどいようですが、そこに登録された価格や納期はだれがどうやって決めたのでしょうか。そこが重要であり、後々にも活かされるノウハウになるかもしれないのです。また、さきほどクラウドでという話がありましたが、クラウドだからいいアプリケーションがあるということではありません。あくまで運用のプラットフォームでしかないのです。ということで、従来のやり方ではビジネス要求を実現するための非定型業務の実装は難しいのです。
  

No TrackBacks

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

Leave a comment

About this Entry

This page contains a single entry by Masanori Wada published on February 9, 2012 1:02 PM.

特許庁のシステム開発の失敗 was the previous entry in this blog.

BPMの最新トレンド is the next entry in this blog.

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

Categories

Pages

Powered by Movable Type 4.34-en