ワークフローオートメーションの位置づけ

　ワークフローオートメーション（以下、ワークフローと略す）は、ＢＰＲ（ビジネス・システム・リエンジニアリング）のインフラストラクチャとして、その発展が期待されている。現状では、ワークフローをグループウェアの延長として理解していることが多いが、ＢＰＲを目的とした本格的な業務に適用するには、むしろ基幹系システムとして認識するほうが適している。
　本格的な業務システムの構築には、詳細なデータフロー分析や基幹系システムでのデータベースとの連携が必要である。ワークフロー管理システム（以下、ワークフローソフトと略す）も、その機能を持ってはいるが、現状では本格的な業務システムを構築するには不十分である。
　データフロー分析にはＤＦＤ（Data Flow Diagram）技法が確立されているが、それを取り込んだ総合的な開発方法論やツールに発展することが期待される。

１　ワークフローの概要

１．１　ワークフローの定義

　初期の代表的なワークフローソフトであるStaffwareを発表した英ＦＣＭＣ社は、ワークフローを「事前に定義された目的を遂行するグループに対し、ルールに基づいた処理を実施し管理すること」と定義している[1]。１９９１年のCSCW & Groupwareコンファレンスでは、グループウェアを「グループ作業を支援し増力するソフトウェア」と定義している[2]。これから見ると、ワークフローはグループウェアの一部であり、特に定例的業務を対象にしていると考えられる。
　また、ワークフローソフトの標準化団体であるＷｆＭＣ（Workflow Management Coalition）は、１９９４年にワークフローを、「ビジネスプロセスを、全体的あるいは部分的に、コンピュータを利用して促進あるいは自動化すること」と定義している[3]。これによると、基幹系システム（販売情報システムや経理情報システムのような、企業の業務遂行に必要な全社的システム）ですら含みかねない。
　このように、ワークフローは、グループウェアの側面と基幹系システムの側面を持っているのである。

１．２　本稿でのワークフローの例示

　ワークフローの対象業務には、出張申請業務のような小規模でローカルな業務（情報システム全体には影響の少ない業務）もあるが、本稿でのワークフローとは、次の貸付審査業務システムのように、大規模で企業活動の中核になるものを対象にする。
　融資申請を受けた担当者は、貸付判定基準を調査し、満足していれば貸付申請書を作成して支店長にまわす。支店長は自分の決裁範囲の事項であれば決裁し、そうでないものは自分の意見をつけて本店の審査部に送る。審査部も同様な手続きをして、最終的には本店役員の決裁を受ける。決裁後はこのルートを逆に戻り、担当者が客先に連絡する。この間の情報伝達は、すべて書類で行われるので、各工程間の受け渡しに長時間かかるし、各部門の労力もかかる。
　ワークフローを導入すると次のようになる。担当者が申請書を電子帳票としてデータベースに入力する。システムが案件内容により回送ルートを決定し、支店長や審査部に未承認申請があることを伝える。承認すると次の工程に配送される。システムが承認基準などをデータベースから引き出して自動付き合わせをするし、電子帳票の様式を画面表示するので、操作は簡単になり、例外事項以外は専門家でなくても処理ができる。これにより、各工程での受け渡し時間が短縮され、申請から承認までの時間が短縮されるので顧客満足にもなるし、廃止できる工程もあるので業務削減にも効果がある。

２　ワークフローの現状

２．１　ワークフローへの期待

　メインフレームからＣＳＳへのダウンサイジングが進行している。最近ではメインフレームの必要性も見直されてはいるが、全体的な流れとしては、現場に密着した業務分野では、ますますＣＳＳ化が進むであろう。
　ＣＳＳの普及に伴い、グループウェアの導入が活発である。ところが、その利用が進むにつれて、電子メールや電子掲示板などの非定型的な文書情報だけでは満足できず、定例的な業務にも適用することが期待される。それに適しているのがワークフローである。
　未だＣＳＳは信頼性に劣る面があるが、今後急速に改善されると期待されている。それに伴い、メインフレームが中心であった基幹系システムも、次第にヒューマンインタフェースに関する部分から、ＣＳＳ環境での利用に進んできた。ワークフローは、ＣＳＳを前提とした新しい形態での基幹系システムであるといえる。
　ＢＰＲのブームは沈静したが、現実の企業では、実施が行われている段階あるいは実施の成果が見えだした段階である。ＢＰＲで重視されるのが業務のシームレスなシステム化である。情報技術は、それを実現するためのイネーブラであるといわれているが、ワークフローは、そのイネーブラとして最も有効な情報技術の一つである。前掲のＷｆＭＣの文書[3]でも、「ワークフローを導入することによりＢＰＲが達成できるとはいえないが、ワークフローの技術は、ビジネスプロセスの継続的な改善を可能にすることに役立つ」という趣旨のことを述べている。
　このような期待に応えて、ワークフローソフトが多く発表されている。１９９５年頃からは国産のソフトウェアも出現した[4]。ワークフローシステムは、今後急速に発展する情報技術分野である。

２．２　日本でのワークフローの動向

　ワークフローソフトには、業務統合パッケージから発展したものと、グループウェアから発展したものの二つの系列がある。
　最初のワークフローソフトであるStaffwareは、財務パッケージがベースになっており前者に属する。しかし、この系列のものは、ＵＮＩＸを対象にしており、日本では基幹系システムのＣＳＳ化が進まなかったので、前者の系列はあまり普及しなかった。
　日本では後者の系列が多い。日本では、ＣＳＳを構築すると、電子メールや電子掲示板などのグループウェアを実施することが多い。そして、多くの企業でＣＳＳの導入が盛んになった時期に、Lotus社のNotesが紹介され、その傾向がますます増加した。グループウェアの利用が進むに伴い、電子稟議などの半定例的な回覧業務にも利用したいとの要望が、ワークフローに結びついたと思われる。
　ワークフローはＢＰＲとともに進めるべきだといわれている。日本でもその観点から構築した本格的なワークフローの構築事例も発表されている[5]。しかし、現在のワークフローのほとんどは、出張申請やパソコン購入申請のようなグループウェアの発展形態でのローカルで小規模なものである[6]。
　最近は、ＳＡＰ社のＲ／３に代表されるＥＲＰ（Enterprise Resource Planning：全社統合パッケージ）が注目されている。ＥＲＰは主に基幹系システムを対象としているが、最近はＥＲＰにワークフロー機能が組み込まれるようになってきた[7]。ＥＲＰは前述の２系列の前者に属するものであり、ＥＲＰの効果をあげるにはＢＰＲを前提にする必要がある。
　すなわち、日本でのワークフロー利用は、未だテスト的利用段階だといえる。その利用目的は、理念はともかく実施ではグループウェアの延長であった。それが、ＥＲＰの普及に伴い、本格的なワークフローへと発展する段階にさしかかってきた。

３　ワークフローの位置づけ

　前述のように、ワークフローはグループウェアと基幹系システムとの中間的な位置づけになる。しかし、システム開発や運営の観点からは、基幹系の一部だととらえるほうが妥当である。

３．１　ローカルなワークフロー

　出張申請のようなローカルな小規模ワークフローを構築するには、グループウェアと同じようなアプローチでも対処できる。
　グループウェアは、電子メールや電子掲示板に見られるように、非定例的であり非定型的なものである。ユーザアドレスや掲示板データベースなどの全体的な管理は、情報システム部門などが集中して管理する必要があるが、それらへの入力や検索などの実務的な運用は、むしろ利用者間での自律的な運営に任せるほうが有効である。掲示板の設計も利用部門での情報リーダなどが中心に設計したほうが、使いやすいものになる。
　小規模でローカルなワークフローは、運用上、少々トラブルがあっても、それが企業運営に打撃を与えることは少ない。信頼性よりも有効性、標準化よりも使いやすさや小回りのきくことのほうが重視される。そのために、これはグループウェアと同じような運営をするほうが効果的である。

３．２　本格的ワークフローの要請機能

　それに対して、本稿の対象である前述の審査業務のような中核的で大規模な業務を対象としたワークフローは、次に列挙するような機能が要請されるが、これは基幹系システムへの要請と同じものである。
・信頼性の要請
　対象が企業運営の中核業務であるから、機器や回線のトラブルにより、利用できないことがあっては困る。入力情報が伝達途中で脱落したり改変されては困る。
・正確性の要請
　情報が正しいものでないと困る。それには、入力時のデータチェックや誤操作を防ぐためのしくみが重要である。
・標準化の要請
　正確性を担保するには、すべての操作システムを統一した基準で構築する必要がある。それには、各部門での業務の標準化と、システムでの標準化が必要になる。
・記録性の要請
　このような分野での情報は、運営のためにも監査のためにも、長期間保存して後日の検索ができることが必要である。また、これらの情報は基幹系システムでの入力データになることが多い。このようなデータをサーバに置いて利用部門に保存管理させるのは不適切である。最終的には、情報システム部門のメインフレームに移して、基幹系システムと連携させたり、基幹系システムのデータと同様な保管をするのがよい。
・統合化の要請
　このようなワークフローのシステムは、他のワークフローシステムや既存の基幹系システムと連携させる必要がある。そのために、個々のシステムとしてではなく、全体的な統合システムとして位置づけるべきである。
　このような要請に応えるためには、グループウェアのように利用部門の自律的開発や運営に任せることは危険である。情報システム部門などの全社的機関が、システムを開発し、運営することが必要になる。当然、利用そのものは分散するが、全体としての運営管理は集中する必要がある。すなわち、本格的なワークフローは、基幹系システムとしてとらえるべきなのである。

３．３　基幹系システムからの要請

　現在の基幹系システムでは、端末からデータ入力をする。入力画面はヒューマンインタフェースが重視されており、データの正確性をチェックする機能が組み込まれており、データ入力時に帳票が得られる。情報出力の多くも端末側で検索でき、必要ならば各種データベースを参照することもできる。すなわち、データ入力と情報出力の部分では、ワークフローも基幹系システムでも大差はない。
　しかし、担当者の業務としては大きな違いがある。データ入力までには、データの発生を伝達したり入力の承認をするなど、入力データを整えるための多くの作業が必要となる。入力時に得られた帳票帳票はコンピュータ処理とは別途に社内を流れることが多い。すなわち、従来の基幹系システムは、点としての業務のシステム化であった。それをシームレスにシステム化するには、ワークフローをシステムの一部として組み込まなければならない。
　また、従来の基幹系システムは数値情報の加工が主体であったが、上述にような業務を取り込むには、文章情報、場合によっては画像情報も必要になる。マルチメディアの取扱はワークフローのほうが優れている。
　このように、これからの基幹系システムはワークフローと融合したものになることが予想される。

４　ワークフローとＤＦＤ

４．１　両者の相似と相違

　基幹系システムのシステム設計には、ＤＦＤ（Data Flow Diagram）が有効であり、普及している。それに基づくシステム設計方法論も確立している。ワークフローでは、プロセス定義（Process Definition）がそれに相当するが、この両者は、業務分析をして情報の流れに注目するものであり、両者の構成要素も外見上も非常に似通っている。
　しかし、現状ではこの両者には相違点も多い。ＤＦＤはメインフレームでの大規模業務を対象としている。ＣＡＳＥツールの機能として実装されるが、ＣＡＳＥツールでのＤＦＤは、システム（端的にはプログラム）を作成するための上流工程であり、ワークフローソフトのような実行シミュレーション的な機能は持っていない。また、データ入力や帳票作成などの具体的な処理は下流工程に属しており、ＤＦＤ記述時にそれらを直接に作成するのは難しい。これらの理由により、プロトタイプ作成ツールとしての取扱が不十分である。
　それに対してワークフローのプロセス定義機能は、ＣＳＳ環境での比較的単純小規模なシステムを対象にしている。プロトタイプ的に、すぐに実行したり変更することが容易である。しかし、現状の物理モデルを記述するには適しているが、抽象化して改善するためのツールとしては不十分である。大量データの処理は想定していないし、数値加工処理も不十分である。外部情報を参照したり更新する機能は持ってはいるが、大量データでの効率性や信頼性などへの考慮は不十分である。
　ダウンサイジングの傾向は進むにしても、全社的なシステムでの大量データ処理のためには、これからもメインフレームは（ハードウェアの種類や担当する処理目的は変化するとしても）残るであろう。ワークフローを基幹系システムに適用するには、現在ではメインフレームとの連携に問題がある。

４．２　統合方法論の必要性

　このように、本格的なワークフローを構築するには、両者とも欠けているところがある。その隙間を埋めることが重要である。
　ＷｆＭＣでは、各社のワークフローソフト製品の相互連携を図るために、次の５つのインタフェースを定義した[3]。海外および国産の多くのワークフローソフトが、これに準拠しつつある。
　１　ワークフロー定義の互換性
　２　クライアントのアプリケーション
　３　外部アプリケーション
　４　ＷＡＰＩ（ワークフローＡＰＩ）での相互運用ファンクション
　５　システム管理とモニタリング
　ここでも３により、他システムとの連携が考慮されており、多様なシステムがアプリケーション・エージェントを介して利用できることになっている。しかし、それで基幹系システムとシームレスな連携ができるようになるには、各ベンダの環境整備が必要である。
　問題はソフトウェア環境の整備よりも、システム構築技術にある。一般の企業ではこの分野でのシステム構築経験がない。外部コンサルタントに頼るにしても、コンサルタント自身が経験がないのが現状である。このような状況では、グループウェアと比べて非常なコスト高になるであろうし、リスクも高いので、普及がおぼつかない。
　それを円滑にするには、ワークフローソフトにＤＦＤ（あるいはＣＡＳＥ）の方法論を取り入れることて、統合的なツールを提供することが期待される。

おわりに

　今後の情報システムでは、ワークフローが大きな存在になると予想される。未だこの分野は発展途上にあり、今後、多くのアプローチが行われるであろう。ここでも言及したＥＲＰの動向もその一つであるし、ＷＷＷブラウザを取り巻く動きもこれに大きな影響を与えるであろう。
　本格的なワークフローを構築するには、これが基幹系システムであることの認識が必要なことを述べた。現在でのワークフローはグループウェアの発展形態が多いが、そのようなアプローチで本格的なワークフローに取り組もうとしたら、思わぬ多大のコストがかかり高いリスクがかかるであろう。
　新形態の基幹系システムとしてのワークフローを成功させるには、単にツールの機能が発展するだけではなく、従来の基幹系システムの開発技法であるＤＦＤとワークフローのプロセス定義を統合することが重要であり、その統合の上に立った開発方法論を構築することが重要である。