SE関のノーツ/ドミノ徒然草: 第8回 紙という制約からきたワークフロー

ノーツの導入を検討されているお客様の情報システム部門の方に、『どんな利用を想定されていますか』という質問をすると、多くの場合『ワークフローのシステム化で各種業務を効率化したい』という答えが返ってきます。確かにグループウェアであるノーツは、電子メール、情報共有とともにワークフローもたいへん得意な分野ではあります。ただどうもこのワークフローという分野、電子メールや情報共有に比べてなんとなく地味で、実際にシステム化してもユーザーには手放しで喜んでもらえないという印象を私自身持っています。今回はこのワークフローのシステム化について考えてみましょう。

Lotus クライアント テクニカル プロフェッショナルズ, ソフトウェア事業, 日本アイ・ビー・エム株式会社

Lotus クライアント テクニカル プロフェッショナルズ, ソフトウェア事業, 日本アイ・ビー・エム株式会社



2008年 5月 13日

ワークフローと言っても実際はかなり多様でいろいろな業務があります。例えば交通費清算に代表される日常の伝票事務業務とか、予算などの申請のための稟議業務、また基幹的な顧客向け業務として銀行であれば融資の審査業務、保険会社であれば保険金の適用に関する審査業務、また関連社内部署に各種許可をとりつけるための申請や、果ては単純に情報の伝達のために文書を回覧するものなどいろいろです。それぞれの業務は確かに紙を順次、人から人へ手渡し、承認や確認の印鑑を押してまわったりするもので、その実態としてはワークフローと言えるでしょう。

さてこれらをノーツでワークフローのシステム化をします。どんなメリットがでてくるでしょう。『書類が回るのが速くなった』、『どこで停滞しているか分かるようになった』、『処理が定型化された』などが一般的に言われているものです。ただどうも実際のユーザーの声にはこんなものもあります。『PCが1人1台でないので実際に処理するまで何日もかかった』、『今までやっていた例外的な処理ができなく硬直的になった』、『人事異動が速やかに反映されず時期によって使えない』などあまり良い反応は聞かれない場合があります。それだけでなく、ある場合では『使いにくい。遅い。柔軟でない。』というユーザーの大合唱から廃止にいたった例もあります。

ではそもそもワークフローをシステム化するということはどのようなことなのでしょう。実際のワークフロー的業務を観察してみるとそれは少しずつ見えてきます。最初は単純に見えていた書類の手渡しが、実際は途中で少し戻ってみたり、ある人を一時的に飛ばしてみたり、実際の人ではなく別な代行的な人が処理したり、果ては電話で了解をとって業務は実際行われている状態で後から書類が回ったり、と実にさまざまです。これをシステムの上でやろうとすると、全ての場合を洗い出し、例外を例外ではなく通常の業務として定義しなおしてみたり、とまさに今まで基幹業務アプリケーションの要件定義や設計でやってきたことを同様に行わなければなりません。つまりシステム化は、良く言えば柔軟で複雑なワークフローを再定義し固定化すること、悪く言えば硬直化することに他なりません。

つまり現実のワークフローは多くの場合、実に柔軟なのです。紙という便利な媒体は、基本的な流れだけをそこに記述してあるだけで、実際にはそれを扱う人の判断によって自由に扱うことができます。最終的には業務の終了時点であたかもその基本的な流れのみを通ってきたかのような証拠、印鑑が押されていればよいのです。それは業務の性格上、慣例的にそうなっている場合もあれば、業務を処理する人の判断によってそうなっているというような属人的な場合もあります。まさに紙は自由自在です。これをシステムという融通のきかないものに入れるのですからシステム化というのは大変です。

一方、逆に紙という媒体の制約から決まっているものもあります。コピーという便利なものがありますが、通常ワークフローではその慣例か手間などを考えてかコピーを使わずに同じ書類を順次まわしていきます。一つの書類をまわすと考えると、その書類の発信元では『偉くない順番にまわそう』とか、また逆に書類によって情報を伝える場合には『偉い人から順番にまわそう』とかという慣例のようなものができてしまいます。こう考えていくと、現在の多くのワークフロー的業務は、こういった紙の制約と組織の序列のようなものとが結びついて、現在の姿ができているような気さえしてきます。

もちろん組織ですから決済などを伴う業務では組織の下のほうから書類をまわして次々に決済をとる必要があることも事実かもしれません。ただこの決済とか承認と言った印鑑もよく観察してみると、いろいろな性格のものがあることが見えてきます。課長が印鑑をおせば決済なのにそれを部長などの上にまわして確認させる印鑑。本来は本部長の印鑑が決済なのに課長や部長がその案件を知りたいために書類をまわして押す確認の印鑑。文書の回覧だけでただ見たことを示す印鑑。こう考えていくと、システム化すれば同時に書類を配ったりすることでなくせる印鑑なども数多くありそうです。

このように紙という媒体の自由度とともに制約、そして組織の序列が密接に結びついて形作られているのが、現在のシステム化以前のワークフロー業務と言えなくもありません。これをシステム化して紙を廃止するのがワークフローシステムです。媒体が変わるのですから当然その流れややり方なども変わらなければ、不自然とも言えます。紙のやり方を変えなければ、逆にシステムという制約、流れを簡単には変えられないとか、システムから取り出すのにわざわざ印刷する必要があるとか、そういったものが紙の制約でできたやり方に加えて、ワークフローシステムに『使いにくい。遅い。柔軟でない。』というデメリットをもたらすことになるでしょう。

さあもう一度、現在のワークフロー業務を見直してみましょう。重要だと思っていた多くの印鑑が実は読んだ確認だけで、結局は最後の一つの印鑑が決済かもしれません。決済の時間を短縮するのが目的であれば、いっそのこと決済された後に関係する人にコピーを配るようなシステムにできるかもしれません。場合によっては決済などない、という文書の回覧だけのものもあるでしょう。これなら一斉にコピーを配ればそれで済むかもしれません。つまりワークフローと思っていた部分が実は情報共有だったのです。紙という制約がそれを流れにして、確実に見たことを確認するために印鑑の欄があったのです。

もちろん最初にもとりあげたように、ワークフローと言っても基幹的業務から回覧的業務までさまざまです。これら全てが同様に大きく変えられるものではないかもしれません。特に基幹系の業務は本質的に決済の意味が重く、そう簡単に流れは変えられないかもしれません。ただ最近、製造業などで製品の設計と生産をワークフローだったものを情報共有によって同時進行させて、製品の質や開発期間を劇的に短縮するような例がとりあげられていたりします。ここまでくればワークフロー業務の見直しという簡単な言葉でなく、業務の再構築とも言えるものでしょう。しかしこのような例も元をたどれば『果たしてこの業務はワークフローか?』という根本的な問いであることは確かです。

ノーツのようなパッケージ的なソフトウェアが数多くでている最近では、お客様の情報システム部の仕事も次第にプログラミングなどの技術的で負荷のかかることから開放されつつあります。一方システム化も基幹業務が一通り終わり、あとはホワイトカラーなどの複雑な、システム化しにくい業務がクローズアップされています。そのような状況で、ユーザーにより満足なシステムを提供するためには、情報システム部門の役割として、ワークフローに代表される複雑な業務を見直していくことに他ならないのかもしれません。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=339002
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第8回 紙という制約からきたワークフロー
publish-date=05132008