プロセスということ
制御については、Information Driven Control（IDC 情報駆動制御）という概念を提示したが、この話にいく前にプロセスということについて考えてみる。
プロセスというと業務プロセスだけではなく、製造工程をさすこともあったり、それこそシステム開発の過程もプロセスである。筆者は若い頃石油化学プラントのプロセスエンジニアをやっていたので、プロセスというと化学製品の生産プロセスを思い浮かべる。この生産プロセスのライフサイクルを考えてみて、業務プロセスと対比してみる。
まず、開発だが生産プロセスの場合は最初はそれこそ試験管からは始まって、パイロットプラントを経てスケールアップされて、完成プロセスとなる。ここでは、もちろん反応方式が違うとかいったことも大きいが、このスケールアップというのが重要なファクターになる。業務プロセスの場合はいきなりどんと全社システムの導入のようなやり方になる。
システム開発ではこのスケールアップというステップがとれないし、これは生産プロセスも同じだが、一部を動かして順次全体に拡げていくというのも、無理すればできないこともないが難しい。ここが、システム開発のやっかいなところで、そのため導入時にはいくつかの弊害がでてくる。
例えば、業務間あるいはシステム間の全体整合をとるためにすごい苦労をしたり、プロジェクトの最後にはやみくもにコーディングして後で泣くとか、長いテスト期間をとるとか、そういった一発勝負的な開発が多いような気がする。ただし、これは今までの話であって、これからはこの問題についても解決手段として、BPM on SOA
が有効になる可能性があると思っている。
ここで忘れてはいけないのが、全社リソースデータが一元管理できていることが重要な前提となることである。スケールアップや順次稼動の場合、個別にデータベースを作っていたのでは、整合性のとれない“サイロ”システムを生み出すだけになるおそれがあるからである。
さて、生産工場などにおけるプロセスはどのように可視化されているかというと、実物の機器や配管などが目で見えるというのも大きな違いであるが、関係者がコミュニケーションできる共通の図面の存在も違いのひとつではないだろうか。
プラントでは、オペレーター、スタッフ、保全担当、安全担当などの人々は、何かあると必ずP&ID（Piping & Instrument Diagram）というものを見ながら話をする。文字どおり、プロセス流体の流れ、遷移状態、プロセス変数などがすぐに分かるようになっている。それと、配管図や機器図などを参照していけば、プロセスは可視化できるのである。
翻って、業務プロセスはどうか。このP&IDに当たるものがない。配管図や機器図に当たるものは、ネットワーク図やハードウエア構成図などがあるが、プロセスの動的な部分も含めて、流れの状態がわかるような図面がないように思える。業務フロー図、業務マニュアルがあるじゃないかといわれるかもしれませんが、それで制御できるのだろうか。
ここで強く言いたいのは、同じプロセスという概念で扱うのであれば、ただ開発したらあとはエンドユーザのひとにおまかせと言うのではなく、その後の制御、維持、改善を考えたライフサイクルを意識することが大事だということである。
特に、生産プロセスの場合は、制御というところにすごく重きを置いているわけで、そのためには、プロセスの設計には現場のオペレーションする人たちのかかわり方が強くある。自分たちがオペレーションしなくてはいけないプロセスは自分たちで考えようじゃないかという当たり前の話なのだ。
従って、業務プロセスの設計・開発にもあとで実際にそのプロセスを使ってオペレーションする人の参画を濃いものにしていかなくてはならない。これは、開発側の問題でもあり、ユーザ側の問題でもある。もちろん、ユーザ参画はいまでもやられているプロジェクトもあるが、もう少しその気になった参画と、あとの“制御”という考え方を取り入れた設計を行なう必要があると思う。
制御だけではなく、維持、改善というプロセスについても、生産プロセスの場合はかなりシビアに管理している。従って、業務プロセスの場合もこうしたことを含めたライフサイクルが非常に重要なことになる。