メイン

業務プロセス設計作法 アーカイブ

2008年5月13日

業務プロセス設計作法 ~ はじめに ~ 

これから何回かに分けて、上流設計にあたる業務プロセス設計について書いてみようと思います。

以前にも「ユーザ目線のBPM」で触れていますが、より具体的な方法を提示していきたいと思っています。これまでは、どちらかというと業務フローができたら、基本的にはノンコーディングでシステム構築ができることを説明してきていますが、その上流のところの話になります。実はここが非常に重要であると同時に難しい領域なのです。

ですから、今までも再三言ってきていますように「シンプルで一貫化されたきれいなプロセス」が書けたらそれでおおかたのシステム構築が終わってしまうということになりますので、そのきれいなプロセスをどう書くかがますます大事になるのです。

そこで、この業務プロセスを書くための作法についてひとつずつエントリーしていくことにします。本技法ではつぎに示すような16の作法からなっています。この作法に従って業務プロセスを作っていけば容易に実装までもっていけることを示せたらと思っています。

1.プロセスの特定
2.プロセスの始点のアクティビティと書類化
3、受付タスク管理
4.プロセスの終点のアクティビティと書類化
5.コンテ(業務・仕事のあらすじ)の作成
6.最終書類の必須データ項目
7.中間アクティビティの書類化と確定データ
8.中間書類の内容
9.分岐のタイプ
10.サポートシートの記述
11.きれいなプロセスにするための7つのチェックポイント
12.スイムレーン
13.データベースとデータディクショナリ
14.ビジネスルール
15.帳票
16.実作業の扱い
 

2008年5月14日

業務プロセス設計作法 ~なぜ“作法”なのか~

設計というと手順とかメソッドとかいった言い方の方が一般的であると思いますが、それだと何となく論理的なにおいがしないでもなく、ソフトウエア工学ですねみたいになります。しかし、よく考えてみると業務システム開発って工学的でしょうか?

少なくも、業務モデルは工学的モデルではないように思います。なぜでしょうか。それは人間が介在するものだからです。すなわち、恣意的であり、揺れたり、属人的であったりするのです。

とはいえ、全くカオスにできているわけでもない。厳密ではないにしても何らかの約束事はあるように思えます。別な言い方をすると、約束事ができるようなところとそうはできないところを分離して考えられそうだということです。

この考えが生まれた背景を少しお話しますが、ぼくは元々ケミカルエンジニアで化学プラントのオペレーションやプロセスエンジニアリングをやっていました。そのときの経験や考え方をときどきビジネスシステムにも重ね合わせて見ることがあります。そうですよね、同じプロセスという言葉を使っています。

それで、違いは何かということを考えたとき、真っ先に浮かぶのは、ビジネスプロセスにはオペレーションとかコントロールという概念が乏しいよねということなのです。それは、なぜかというと、どうもプロセスに人間が入っているかいないかの違いではないかと思ったのです。

ということは、人間が入ってくると、オペレーションやコントロールが難しいということを意味します。化学プロセスでは少なくともプロセスフローには人間が登場しません。人間が登場するのは、オペレーターとして、プロセスのオペレーションとコントロールを行います。ここが大きく違うように思えます。

そうであれば、そうしたことができるような構造にするには人間系をはずしてみたらいいのではないかと考えたわけです。

そして、ただはずしただけではいけないのでそれらはCMS(Contents Management System)に預けたわけです。ということでBPMSで扱うコンポーネント(アクティビティ)を書類という“箱”にして、ある程度約束ごとをもったものを登場させたというわけです。

化学プロセスも単位操作(加熱、冷却、圧縮等の処理)の連なりであり、それらが非人間系なので法則性があり論理的なプロセスが形成できる。ですから、書類を作成して発行するというのを化学プロセスの単位操作と同じようにハンドリングすればいいのです。しかも、組織というこれまた非論理的な要素もこれで排除できます。これはスイムレーンの問題なのであとで詳述していきます。

さて、おわかりになってでしょうか。ある切り出し方をすれば化学プロセスのように、あるいはエンジニアリング的にやれるのです。

そして、残った部分は人間系であり、恣意的な要素になりますが、これらは思い切って人間くさい“ゆるい”場所(情報共有の場)にもっていってしまうのです。こうした構造化がこの技法のポイントのひとつです。

一方、開発サイドからみると、上述のように工学的な問題に近づけたとしても、まだあいまいさは残り、そうしたモデルでも作るときはみなばらばらになっても困るわけで、それなりの集団としての秩序が維持されなくてはいけません。

そうした場合、これはいったい何をもってその秩序とやらを、また約束事を担保できるかと考えると、それは“お作法でしょ”ということになります。作法は「型である」と言えます。ですから、基本的な型を決めておくということになります。

よくある開発方法論などは、どうしても工学的なアプローチやプログラミング的なアプローチであり、ビジネスの観点からすると、すごくなじみがなくわかりずらい面があったように思います。「作法」というと、それほど確固としたものではなく、だいたいこんな風にしたらいいぐらいの感じで決めていけばいい。ただし、芯ははずさないようにすることが大事です。

ですから、作法に則ってやっていけば、誰でもほぼ同じような業務プロセスができてくるのです。ここが非常に重要なポイントになります。

こうして作られたものは、ある意味狭い範囲ではあるかもしれませんが、標準化されたものであるといえます。そうすれば再利用性が高まることは言うまでもありません。

作法は型なのでそれを表現するための様式も用意する。基本は書類に相当する“シート”ですが、そのほかにも“カード”、“サポートシート”があり、それらを綴じると“ブック”になり、これは業務プロセステンプレートになります。これらの“ブック”を集めたものが“ライブラリー”となります。それぞれの概要はつぎのとおりです。

ライブラリー:ブック(業務プロセス)を集めたものでインデックスを貼って分類する。
ブック:シートを時系列的に並べて綴じたもので、業務プロセスを表現する。
シート:業務機能コンポーネントを始点シート、終点シート、中間シート、サポートシートとして作成し、シートにカードを貼り付ける。コンテを書いてから作成する。
サポートシート:意思決定をサポートするコンポーネントで主にEXCELのようなスプレッドシートで管理する。
リレーションカード:シートにおいて参照、連絡、分岐などの関係性を表す。参照カード、連絡カード、サービス連携カード、分岐カードなどがある。
%E4%BD%9C%E6%B3%95%EF%BC%88%E5%9B%B3%EF%BC%89kailasBook.jpg
こうした作法に即した体系で自分たちの業務プロセスをドキュメントとして残しておき、ビジネス環境の変化に迅速に対応していけるようにしていくことが重要となってきます。

さて、次回は前提となる考え方について書くことにします。
 

2008年5月15日

業務プロセス設計作法 ~作法を考える上での前提~

これから提示する作法は、もちろんどんなものにも適用できるかというとそうではありません。まず、注意しなくてはいけないのは、実装を意識したボトムアップの手法だということです。

事業戦略とかビジネスゴールから業務プロセスに落とし込んでいくトップダウン手法がありますが、本作法はAsIsベースのボトムアップ手法です。実際には両者の組み合わせでおこなうハイブリッド型のアプローチが有効になります。

こうした組み合わせもケースでいろいろなやり方がでてきます。AsIsのプロセスを切る出して、そのプロセスをベストプラクティスモデルと突き合わせて改善していくというオーソドックスな場合や、新規事業などはそのままモデルを適用する場合もあります。また、IT化のレベルが低い会社などでは、まず現状のシステムの見える化をするだけで十分だという場合もあると思います。ですから、トップダウンだとかボトムアップだとかはあまり気にしない方がいいのかもしれません。

要は、自分たちが現に行っている事業がどういう業務プロセスから成り立っていて、それが役に立っているのかを把握できるかである。それが分かれば、今のままでいいのか、変えなくてはいけないのかが明らかになるのではないでしょうか。

基本的には、「書類コンポーネントをベースにしたCMS-BPMSを使った業務アプリケーション構築」のための設計になっています。

ただし、それだけに特化したものでもありません。プロセスというものは機能の組合せで成り立っていることは何度も申し上げていますが、その機能をコンポーネントと捉えていく考え方であれば適用は可能です。すなわち、そのコンポーネントを書類というようなオブジェクトを想定するのか、また違ったものに定義してもかまいませんが、同程度の粒度でみているものであれば、同じように設計が可能です。

BPM(Business Process Management)アプリケーションを考える場合は、多くの場合はマスタデータは整備されているという前提に立ちます。業務プロセスをまわすために必要なリソースデータ、例えば、顧客、取引先、商品、従業員マスタなどは既に用意されていて、それらを参照するようにしています。

ただし、BPMでももちろんデータを扱いますので、データディクショナリーを保有し、データの一貫性やデータベースの重複の回避など、整合性を保つ必要はあります。

もし、整備されていない場合はデータモデリングから入り、マスタの構築を行ないます。

同じように、ビジネスルールについても、別途保持しているという前提です。それらのルールに従って、分岐の発生や意思決定の方法が規定されていきます。もちろん、そのプロジェクトで新たに出てくるビジネスルールもあります。

こうした、前提条件についてもこれからの作法の中に出てきますのでそこでまた議論したいと思います。

2008年5月16日

業務プロセス設計作法 ~前提の補足説明~

この作法では書類というコンポーネントを主体にお話していますが、書類という類型化された整理の仕方になじまない方もいらっしゃるかもしれませんので、何がなんでも書類にするということではないということです。前回も“同程度の粒度のものであれば”ということを言っていますがそこをもう少し補足しておきます。

大事なことは書類にすることではなくて、書類の作成から発行までがちょうど業務処理の単位と同じであると言っているのです。同時に、その書類を作るということは何かのデータを確定することを意味しています。ここが重要なポイントで、ですからもし書類がいやなら、“確定シート”でもかまわないのです。

従来の考え方でみると、といってもBPMは最近の話で、BPMでない場合はどうしていたのだろうかというのが気になりますが、モジュールだったのでしょうか?

BPMでもこのあたりの考え方、すなわちアクティビティをつなげてプロセス化するといっても、そのアクティビィティの粒度をどうするのかの答えがなかったのではないのか、というか、統一感を持った粒度設定ができていないと思います。

そこがこの作法の肝です。データを確定するためにする振る舞いは別の場にして、順番にデータを確定しながら業務を進めていくということがプロセスであると規定したわけです。人間系の不安定なアクティビティやアクションを違う場所に移したことが意味があることなのです。大きなプロセスには例外処理のようなものを極力排除していきます。

ですから、ここのルールを守ればいいのであって、この作法で言う「書類」を「シート」と読み替えてもらってかまいません。このあたりは、重要なのでこれから随所に出てきますのでよく理解しておいてください。

2008年5月19日

業務プロセス設計作法 ~作法その1~

プロセスの始点と終点を決めます

まずは、プロセスの始まりと終わりを決めていきます。これは単純なことなのですが意外と重要なことです。よくプロセスがどこで始まってどこで終っているのかがよくわからないものを見かけることがあります。そういうプロセスって本当は必要ないプロセスかもしれません。

それと終わっていることは終わっているのだが単にどこかのファイルにしまっておくだけでほかに何も使わなかったりするなんてこともあります。

さて、ここで始点と終点を決めましょうと言っていますが、どうやって決めたらいいのでしょうか。

プロセスの始まりを考えてみましょう。これは、何かの依頼があって始まります。依頼のされ方も顧客からだったり、上司からだったりといろいろなパターンがありますが、いずれにしろ依頼がきてそれを受付けることから始まります。

それでは終点は何なのだろうか。これは、そのプロセスが何のためにあるのだろうかということを考えてみたらいいと思います。

プロセスというのは最終的にはビジネスの結果を表現することで終わります。もう少し具体的に言うと、リソースデータを書き換えることと新たなイベントデータを生み出すことにつながることです。別な言い方をすると、BS(貸借対照表)とPL(損益計算書)に反映するための活動プロセスなのです。

そうした観点から、始点と終点を特定していきます。詳しくはそのあとの個別の議論で行います。

では、始点と終点のどちらを先に決めるのかという問題があります。それは、お客さんからの要求によりプロセスが提起された場合は始点を先に決めます。また、内部で発生したような場合はBS、PLを意識して終点を先に決めます。

作法その1のポイント
・「○○から○○まで」という風に書き出します。(始点と終点を決めてからでよい)
(例)受注から出荷まで、見積依頼受付から見積まで
・顧客接点のプロセスの場合は始点を先に決める(お客さんの要求が最優先) 
・内部プロセスの場合は終点を先に決める(BS、PLに繋がることを意識)

2008年5月20日

業務プロセス設計作法 ~作法その2~

始点は「依頼を受付ける」ところから始まり、通常「○○依頼受付書(メモ)」が最初の書類となります

プロセスが開始されるのは、どこから依頼があって、それに基づいて行われます。その依頼のされ方はいくつかのパターンがあります。

1)外部からの依頼
2)内部からの依頼
3)ルール化されたトリガーによる依頼

外部からの依頼というのは、顧客や取引先からのもので、その中でも特定されているのか、不特定多数からかに分類することができます。

特定顧客かそうでないかで依頼の受付け方が違ってきます。特定顧客の場合は、おおかたの場合そのまま受付けにつながりますが、不特定顧客の場合は、その顧客が真の顧客になるのかどうかとか、要求をよく吟味しなくてはいけないとかいった前処理が必須となります。

従って、この場合は受付タスク管理の仕組みで一旦オペレーションする必要があります。よくある例はコールセンター機能です。

ここで許可された依頼を後プロセスへとエスカレーションすることになります。

その他では、ルール化されたもののなかでスケジュール化されて依頼がやってくるものがあります。例えば、月末・期末になったら必ず行われるものなどがありますが、これらは自動的に受付されますので、受付というアクティビティはスキップさせることができます。

それ以外では、「○○依頼受付書(メモ)」という書類コンポーネントを起こして受付けることになります。ここには、依頼内容などを5W1Hの観点で書き出すことにします。

もちろん依頼は、様々な手段、例えば電話、FAX、電子メール、Webサイトなどで来ます。ですから、そこから自動的に後プロセスに流すのは危険なような気がしますので、基本的には一旦切って人間が介在させたほうがよいと思います。

もちろんWebサイトからオンラインで取り込むことや受付タスク管理から自動的に書類を起こすこともできます。要件によって使い分けることになります。

作法その2のポイント
・プロセスの始点は依頼を受付けるところから始まる
・ルールが決まっているもの以外は受付タスク管理の仕組みで受付を許可するか決める
・受付タスク管理と下流プロセスへのエスカレーションは手動でかまわない
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%891.JPG
 

2008年5月21日

業務プロセス設計作法 ~作法その3~

受付タスク管理表は、スプレッドシートに依頼事項や受付状況を記載します

その2でも述べたように外部顧客(特に不特定多数の顧客)の依頼については、そのまま受付というわけにはいかない場合が多くあります。そうした場合は、依頼の背景や内容を吟味しながら、あるいはお客さんと会話しながら受付を許可するか決定していきます。

そのための管理シートとコミュニケーションができるものを用意します。そこに、記入し、許可されたものが下流のプロセスに流れていくようにします。

この機能は、大きいものではコールセンターがこれにあたりますし、その他、問い合わせ窓口、苦情相談等々様々な形がありますが、基本的には案件管理の仕組みは同じだと考えています。もし、すでにこうした機能を保有している場合はそれらを活用したらよいと思います。

ただし、ここでのポイントは単に受付担当だけで決めるのではなく、その場に決定権限のある管理担当の人も参加させていくことです。そうすることによりスムーズな意思決定ができるのです。

シートはスプレッドシート型(EXCELライク)のものを使用し、依頼における5W1Hやステータスなどをカラムに設定し、案件ごとに記入します。表はわかりやすいように2階層ぐらいに分けて管理したほうがよいでしょう。

登録された案件にメンバーがアクセスして、顧客との会話あるいは内部メンバーとの連絡・確認を行って受付の許可を行います。

作法その3のポイント
・受付タスク管理はスプレッドシート型の管理表を使う
・5W1Hの観点で依頼内容などを記載する
・下流のオペレーションをする人もそこに参加する

2008年5月22日

業務プロセス設計作法 ~閑話休題(1)~

BPMとワークフローの違い

BPMというとよくワークフローとどう違うのですかと質問されます。今までは、まあ同じようなものですよと答えていました。ASPとSaaSの違いを聞かれたときも同じようにしていました。ただ、よく考えていくとどうもそれではまずいように思え、そこのところをきちんと整理しておく必要があるのではないかと考えたのです。

@ITに日本BPM協会の宇野澤さんが書いた「5分で絶対わかるBPMS」には、BPMSの機能として次の9つを挙げています。

・BPM実行エンジン
・プロセスモデラー
・シミュレーション機能
・組織モデラー
・ワークフロー機能
・ビジネスルール管理
・ソフトウェア開発
・システム連携機能
・プロセスモニタリング機能

このなかでワークフローという機能が出てきますが、簡単にいうとこの機能だけがワークフローにあって、それ以外の機能をもったものがBPMSであるとも言えます。

ただし、そうみるとBPMSがたくさんの機能を持っているように見えますが、必ずしも全部なくてはいけないかというとそうではありません。使う機能には段階があります。

最初に業務プロセスを作って動かすには、BPM実行エンジンとワークフロー機能だけあれば最低限のことはできます。

プロセスモデラー、シミュレーション機能、組織モデラーといったモデリング機能については、プロセスを最適化したり、プロセス変更をしたりする場合に用いられますので、ToBeモデルを書く場合に必要になります。

また、プロセスモニタリング機能はきちんとプロセスが動いてからの話でパフォーマンスなどを測定し改善につなげるわけです。ですからこれはもう少しあとに使う機能になります。そのほか、ビジネスルール管理は別のソフトがあったり、コメントしておくくらいで済んでしまう場合もあります。ソフトウエア開発はそのままフレームワークを使うだけでいいものがありますので、新たに開発はあまりしない方がいいと思います。

ワークフローとの違いの話に戻ると機能の違いというよりその形態の違いが大きいのではないかと考えています。

どういうことかと言うと、両者とも“単位業務処理”という箱をつないでフローにするという基本部分は同じですが、この箱の粒度が違うのではないでしょうか。

すなわち、従来のワークフローと呼ばれた業務アプリケーションはこの粒度が小さいものが多かったように思います。書類作成とか確認とか承認といったようなアクションレベルをつないでフローを作っているように思います。ですから比較的短いプロセス、例えば申請業務や書類の回覧といったものに適用されています。

ところが、BPMSはそうしたアクションレベルのものもありますが、それよりも粒度の大きいアクティビティのレベルを箱にしています。さらにもっと上の階層であるサービスや別のプロセスそのものをも対象にしています。

すこし乱暴かもしれませんが、本技法でいうミクロフローがいわゆる従来型ワークフローでマクロワークフローがBPMということかもしれません。

また、ワークフローは人や組織を意識しますが、BPMSはあまり意識しません。ここのところも違いがあるように思えるのです。(ここは誤解されそうですから後の作法で説明します)

ですから、SOAやSaaSといった概念にフィットするものとしてBPMSが評価されているのではないでしょうか。ここがBPMSとワークフローの大きな違いであると考えています。

単にフローを作るだけのワークフロー製品から業務プロセス、業務アプリケーションを構築する基盤としてのBPMSというような位置付けなのです。

先日のIBMのカンファレンスでも“ワークフローからBPA”というような言い方をされていました。BPAというのはBusiness Process Automationということなので自動化ということがワークフローとの違いであるといった感じで話していました。

ただ、自動化とひと言で言われても、手作業をIT化するのも自動化だし、プロセス全体を自動制御するのも自動化ですから、ちゃんと定義し、使い方を気をつけた方がいいと思います。ですから自動化というよりコントロール&オペレーションの概念が反映されてきているのがBPMだといった方がよさそうだと思っています。
 

2008年5月23日

業務プロセス設計作法 ~作法その4~

終点は最終的なアクティビティとなる書類です

この最終的なアクティビティというのは何のことでしょうか。以下の2つになります。

(1)依頼に対する回答
(2)ヒト・モノ・カネの出入り

ここの(1)の依頼に対する回答というのは、お客さんから依頼されたことに対して、報告や情報提供を行うことである。簡単な例では苦情が来てそれに対して回答するというのもひとつのプロセスになります。書類は「○○報告書」とか「回答書」のようなものが主なものになります。

(2)の場合が少し複雑でよく考えてみる必要があります。本来的には、企業にとっての最終アクティビティはカネにつながるものといっても差し支えないのです。モノを出荷するといってもそれが出荷したところで終わるわけではなく、最終的には代金回収して入金で終わります。例えば、出荷作業が完了して完了報告書ができ出荷履歴登録が終わると、代金請求を行い入金があってプロセスは完結します。

そう考えると大部分がカネになって終わることになるのでそこを最終的なアクティビティとすればよいのだが、それだとプロセスも長くなってしまい、見えずらくなるため、出荷(登録)といった区切りで切ることにします。別な見方をすると、例えば代金回収プロセスなどは上流が違っても共通的なプロセスになるので、モノとカネは別途独立させたほうが分かりやすいとも言えます。

このヒト・モノはカネと切り離してもいいのですが、そうすると何をもって終わりとするのかという問題があります。これは、DBの登録・更新をもって最終アクティビティとみなすことで対応します。

すなわち、前述したように出荷履歴登録などのようにデータベース登録の時点で中間点ではあるが、プロセスの終点ということにします。もう少手前で在庫で一旦終わらせるということもあります。この場合の書類は、「登録依頼書」とか「作業完了報告書」といったものになります。

これは、プロセスの終点は決算書(BS/PL)に繋がるものであるという見方をさしています。言い方を変えると、“勘定科目データ“を生成するためにプロセスがあると考えます。

作法その4のポイント

・終点は依頼への回答とヒト・モノ・カネの出入りで抑える
・DBの登録も中間点であるが終点とみなせる
・決算書のデータを生成するためにプロセスがあるという観点でみる

2008年5月26日

業務プロセス設計作法 ~作法その5~

コンテ(業務・仕事のあらすじ)を作ります

映画を作る場合、絵コンテというものを書きます。場面のイメージを絵にしてそこにコメントを入れて並べたものです。それでだいたいのストーリーとカット割がわかるようになります。いわば映画の設計図のようなものです。

業務プロセス設計においても、これと似たようなものを作るとプロセス全体がどのような構成になるのかが理解できるようになります。業務・仕事のあらすじが表れてきます。

コンテの一枚には、「何かを受付けて、何かを決めて、次に依頼する」という事柄を書きます。これら動作のつながりが全体のコンテとなります。ここで決めるということは、あるデータを確定するというように置き換えて考えたらよいでしょう。

一番最後は“依頼する”ではなく、“登録・報告する”となります。

また、この時点でわかっている参照情報や連携サービスあるいは分岐についても書き出しておいてください。ただし、これはそれほど厳密なものである必要はありません。詳しくはそのあとの書類作成のところで見ていきますので気がついたものを記しておくといったことになります。

あくまで全体感と流れを把握することを目的にしていますので、細かいことより、一枚一枚のコンテの粒度の統一感や連続性を考えて作成することが肝要です。

なお、簡単なプロセスであればこれからすぐに業務フローが書けてしまうケースもありますので、超簡便法としてやっていってもかまいません。

作法その5のポイント

・映画の絵コンテのようにコンテを書くことで全体感をつかむ
・受付-確定-依頼という動作の連なりとして表現する

%E4%BD%9C%E6%B3%95%EF%BC%88%E5%9B%B3%EF%BC%89%E3%82%B3%E3%83%B3%E3%83%86.JPG

2008年5月27日

業務プロセス設計作法 ~作法その6~

最終書類の必須データ項目を依頼に対する答えとしてリストアップします

各書類に関連するデータ(属性値)については、最終書類で必要となるデータ項目から遡って決めていきますので、順序としてはまず最終書類のデータ項目のリストアップをおこなっていきます。

最終書類のデータ項目というのは、最初にあった依頼に対する答えとして存在します。すなわち、簡単な例で言うと、お客さんの問い合わせの回答のようなものです。ここでは、必須データだけをリストアップします。あったらいいなというようなデータ項目は排除しておきます。ちなみに、そうした参考情報は書類の説明文のなかに入れることになります。

まずは、依頼された内容に対して最終的に登録・報告すべきデータ項目を確定します。このときの項目抽出の考え方は、顧客視点と決算へのつながりという意識で見ていきます。お客さんが望んでいる答えになっているかという吟味をします。また、BS/PL(特にPL)につながっているものであるのかどうかというチェックが必要になります。

こうした観点での検討は、後の作法にも出てきますが、「目的合致性」や「プロセスの一貫性」などのチェックとも関係してきます。すなわち、このプロセスは最終的に何をアウトプットとして出そうとしているのか、なぜそれが必要なのか、無駄なアウトプットになっていないかという風にみていくことが大事です。

作法その6のポイント

・データ項目の洗い出しは最終書類のデータ項目の確定から始まる
・必須データだけをリストアップ
・顧客視点と決算つながりの視点

2008年5月28日

業務プロセス設計作法 ~作法その7~

コンテに従って確定データを中心に終点から遡って中間書類を作っていきます

コンテに従って書類を起こしていきますが、終点すなわち最終書類から遡って書いていきます。この前の作法で最終書類のデータ項目が特定されましたが、そこから出発していきます。

始点と終点の間の中間書類は、最終書類のデータに徐々に追記されていくイメージとなります。すなわち、最終書類の一つ手前の書類ではどうなるかというと、最終書類で確定すべき未確定データだけが残ったものということになります。

このように後ろから遡りながら中間書類の書類名、確定すべきデータ、連携サービスなどを決めていくことになります。必ず後ろからでなくてはいけないということではありませんが、ひとつの書類で原則ひとつのデータを確定していくという考え方ですので、最終的なデータ確定に至るにはひとつ前では何が決まっている必要があるのかというようにみると逆流方式のほうがわかりやすいのではないでしょうか。

ここでひとつの書類でひとつのデータを確定するといいましたが、必ずしもそうでない場合があります。例えば、見積を決めるとき数量と金額は一緒にするとかということがあります。そのとき、同じメンバーで同時に決定していくのであれば、複数のデータ確定をひとつの書類で行ってもかまいません。

作法その7のポイント

・中間書類は最終書類から遡って書いていく
・中間書類は確定データを中心にみていき、データを追記していくイメージとなる
%E4%BD%9C%E6%B3%95%EF%BC%88%E5%9B%B3%EF%BC%89%E3%83%87%E3%83%BC%E3%82%BF.JPG

2008年5月29日

業務プロセス設計作法 ~作法その8~

中間書類には誰が何を参照して何を決めるかを書き、連続性のあるものにします

さて、中間書類には何を書いてどんなルールがあるのでしょうか。コンテのところでも書きましたように「何かを受付けて、何かを決めて、次に依頼する」というのが一枚の書類のなかに収まり、それらの連なりで業務プロセスを表現していくことがこの技法の大きな特徴です。

その書類に書くものは基本的には次のようなものになります。

 ・決めるべきデータ
 ・登場人物 ・・・確定(書類作成)する人/アドバイスする人/確認する人/承認する人
 ・連絡・調整先 ・・・どこの部署の誰に連絡するか(と調整するか)
 ・参照情報 ・・・何を参照するのか、その情報名とどこにあるか
 ・分岐 ・・・分岐があったらそのタイプや行き先、判断条件
 ・連携サービス ・・・連携するサービス名とやり取りする情報

次に大事なのは、連続性ということで、書類は依頼と受付で取り合うので前の書類の依頼内容が次の書類の受付内容と一致していることが必須です。

また、処理がひとつの書類で完結していることも大事で、単なる確認や連絡のような処理は対象とはならないということです。言い換えれば、書類の中でデータを確定していくということが書類を作成・発行することにあたります。従って、データを確定していない書類は作ってはいけません。そうした確認や連絡などのアクションは書類の中の会話などで表現されます。

作法その8のポイント

・書類に書くものは、決めるべきデータ/登場人物/連絡・調整先/参照情報/分岐・連携サービス
・前の書類の依頼内容が次の書類の受付内容と一致していること
・処理がひとつの書類で完結していること
 

2008年5月30日

業務プロセス設計作法 ~閑話休題(2)~

プロセスコントロール&オペレーション

前回の「閑話休題(1)」に出てきたコントロール&オペレーションということです。この概念がBPMの大きな特徴であると考えています。これもなぜ“作法なのか”にも書いたことで再三の繰り返しで恐縮ですが聞いてください。

化学プロセスも同じプロセスという言葉を使いますが、そこではプロセスコントロールとオペレーションということが重要視されています。自動制御も行われています。また、シミュレーションにしても工学的なアプローチが行われていてかなり高度な取り組みがなされています。新日鉄の高炉の制御技術が金融工学に応用されて成果をあげている例も有名でご存知の方もいらっしゃると思います。

実は、化学プラントや鉄鋼の高炉、石油精製などにおけるこうしたコントロール&オペレーションの考え方は、ビジネスシステムにも応用されるはずだと思っています。

ではどうして今まで関連性がなかったのでしょうか。それはまずは企業情報システムにおいてプロセスという概念が乏しかったことがあります。EDP(Electric Data Processing)と言ってもプロセスではなく電子データ計算処理のことだからデータを登録して集計するというシステムが主体であったのです。

そこで、BPMというプロセス概念を入れた考え方が登場したわけですが、従来の考え方の延長で見ていると単にデータを登録するためのフローでしか捉えていないということになってしまいます。

プロセスをコントロールして、オペレーションするという管理を適用してこそプロセス化した意味があります。よく可視化とか見える化とか言いますが、単純に見えるようにしてもたいした意味がありません。それらを事業に貢献できるようにコントロールして、継続させる、発展させることが重要になります。

ところで、IBMが言っているような自動化の段階にもっていくのはそう簡単なことではありません。そのための要件があります。(この自動化という表現は、前にも書いたように気をつけた方がよくて、ちゃんと定義しないといけない。これについては別のエントリーで書く)

それはこれも再三申し上げていますが、“人の要素を排除する”ことです。工学的なレベルに近づけようと思ったら、あいまいさは邪魔になります。おわかりのように人間の介在はあいまいさをもたらします。

ですからポイントは、人間を排除した形のプロセスを作れるかになります。そして、化学プロセスの単位操作にあたる業務アクティビティ(コンポーネント)に人間が入らないものにすればいいのです。ここに書類コンポーネントを組み合わせてフローにするという意味があります。こうした粒度設定にしない限り、正しいBPMは実現できないということがおわかりになったでしょうか。

ただし誤解しないで欲しいのは、人間を排除するといってもマクロのワークフローのところでの話であって、正確にいうと排除ではなく、別の適当な場所(ミクロワークフロー)に移すということですので間違えないようにお願いします。
 

2008年6月 2日

業務プロセス設計作法 ~作法その9~

分岐はその種類、分岐の条件を決めてフロータイプを書き出します

分岐にはまず選択型か差し戻し(反復)型があります。これってどこかで聞いたことがあると思いませんか、そうです構造化プログラミングにおける逐次、選択、反復と同じですよね。そうなんです、業務プロセスもプログラミングと同様3つの種類になるというわけです。分岐がないのが逐次型ですから、分岐は選択と反復になります。

さらに、選択の場合は2者択一と複数選択があります。前者は文字通り、ある条件が決まるとどちらか一方に流れていくというもので、オールオアナッシングです。

一方、複数選択の場合は、ある条件で複数の選択肢があり、それが併行的に進むようなことがおきる場合です。

また、分岐したとき並列になる場合とバイパスする場合があります。並列というのは、例えば、同じ処理なのだがそれを行う部署が違うような場合で、見積金額の多寡で本社購買が出すのか工場の購買が出すのかといった業務です。バイパスは処理をとばしたり、違う処理フローになるとかいったものです。

実は、こうしてタイプ分けするのをそれほど重要ではありません。ただ、書類の順番をチェックする、例えば差し戻しのタイプだったら次の行き先が前工程書類であるかどうかといったチェックに使います。

また、プロセスを見直すときの視点を提供してくれるからです。分岐はプロセスを複雑で非効率にしているのでできるだけなくすように努めることが大事です。

作法その9のポイント

・分岐には、選択と差し戻しがあり、さらに選択には、2者択一と複数選択がある
・分岐と書類の順番の整合をとる
・分岐をなくすようにプロセスチェック

%E5%88%86%E5%B2%90%20.JPG

2008年6月 3日

業務プロセス設計作法 ~作法その10~

意思決定支援のための情報はスプレッドシートを活用します

書類というコンポーネントでは、ある意思決定を行います。言い換えれば、書類を作成しそれを編集し、確定した後承認して発行することは意思決定の結果を書類上に記述することに他ならないのです。

こうした意思決定(書類作成)を行なうには、意思決定を支援する情報があります。比較的単純な情報については、CMS(Contents Management System)のリンクやファイルといったコンテンツとして持つことで、そこを参照するという使い方になります。

ところが、もう少し複雑だとか、何か計算やシミュレーションをした結果をみたいだとか、リソースの状況を判断材料にしたいだとかが出てきます。

この場合によく使われるのがスプレッドシート型のものです。そうです、EXCELです。この縦横マスのシートは非常に便利で、計算や集計、事柄の整理、プロジェクト管理などに威力を発揮します。多くの機能がついたソフトウエアもありますが、単純でわかりやすいスプレッドシートをお薦めします。

そして、計算などの数値データを扱う場合はEXCEL、テキストデータを扱う場合はEXCELライクのタスク管理ソフトを使うようにします。

例えば、計算はわかると思いますが、タスク管理ソフトというのは、案件やリソースあるいは要員のアサイン状況、現場作業状況などを縦横の表に書き込むことで共有し、判断のサポートを行なうことができます。EXCELでもできないことはありませんが、コミュニケーションやメールなどと連携したものの方がいいでしょう。

その他には、与信のように外部のサービスを活用するという場合もあると思います。こうしたサービス(プロフェッショナルサービスと呼んでもいいと思いますが)は、最近はSaaS方で提供されるようになってきました。

作法その10のポイント

・意思決定を支援するためのサポートシートを用意する
・サポートシートはスプレッドシートを活用する
・CMSのコンテンツや外部サービスも利用する

2008年6月 4日

業務プロセス設計作法 ~閑話休題(3)~

オブジェクト指向

オブジェクト指向の本(「いちばんやさしいオブジェクト指向の本」(井上樹著 技術SE新書)の書評で今のオブジェクト指向に対する疑問みたいなことを書きました。

その疑問は、要するに、オブジェクト指向分析とオブジェクト指向設計・プログラミングのあいだの溝をどう埋めるかのという問題に帰結します。もう少し言うと、ビジネスシステムの領域のことになるのですが、オブジェクト指向分析がビジネス設計につながらないという大きな問題があるということなのです。

プログラミングにつながる分析・設計はあるのだが、業務システムの設計という視点のものがあるかというとそれがないということが大問題なのです。それに気がついている人がいるのかどうか。

オブジェクトをまだプログラムの固まりという視点で見ているということです。そうではなくてビジネスを作るためのオブジェクト指向設計はどうするんだということなになります。

でここで、オブジェクト指向とBPMを考えて見ます。ただし、そんな深い知識があるわけではないので冒頭の本で得た知識をベースに言います。

ではBPMにおけるオブジェクトとは何かということになる。“オブジェクトとメッセージ”ですよと言われれば、おおこりゃBPMだと思うのです。アクティビティをあるメッセージでつなげているということであればりっぱなBPMなわけです。すぐにこの技法の中の「書類というオブジェクトを依頼と受付というメッセージでつなげていく」いうのがBPMとすれば、おおオブジェクト指向だということになります。

しかし、これはどうもオブジェクト指向分析というレベルのようです。つぎのオブジェクト指向設計という段階はどうなのということになります。ここで問題になるのは、何を設計するかということである。おそらく、ここでプログラム仕様書を作ることに行ってやしないかということなのです。

オブジェクト指向というのはけっこう範囲が広く、これが少し敷居を高くしている可能性があります。要するに分析から、設計、プログラミングまで含んでいるので、ついそれが全部シームレスにつながるようなイメージを持つがこれが曲者で、そこの溝を埋めていくのが難しいことではないでしょうか。

あの本のなかのQAでもそこにふれていて、“ただし、どんな開発であろうと、分析と設計のあいだには、目的の違いが厳然として存在しており、目的を達成するためのアプローチはまったく異なります。ですので、それを一緒にできるということはありませんので、気をつけてください。”と書かれています。

ところで、分析と設計のあいだに目的の違いがあり、アプローチがまったく異なるというのはほんとうでしょうか。それは違うのではないでしょうか。そんなことを言っているからわけがわからなくなると思います。難しいかもしれないがそこをシームレスに近づけることをしていかないといけません。

プログラムを作るためだけのオブジェクト指向ではないのです。そこが間違ってるのです。プロダクトを作るにしても、ビジネスシステムを作るにしても、使う人は自分の思ったように動くITを望んでいます。そういう発想をしたら、分析も設計・プログラミングもつながる話なのです。BPMはこうした思想のオブジェクト指向技法だと考えています。
 

2008年6月 5日

業務プロセス設計作法 ~作法その11~

きれいなプロセスにするための7つのチェックポイント

業務プロセス設計のポイントは、いかにシンプルで一貫化されたきれいなプロセスを作るかにかかってします。そのためには、さまざまな角度からチェックする必要があります。以下にあげるような7つのチェックポイントに従って検討を行ないます。

①【目的合致性のチェック】なぜそのプロセスが存在するかが明確になっているか
②【一貫化のチェック】業務プロセスとデータが途切れず流れているか
③【シンプル化のチェック】業務プロセスが複雑で分かりにくくなっていないか
④【共通化のチェック】業務機能で似て非なるものがないか
⑤【内なる標準化のチェック】同じ業務処理なのに部署によって違っていないか
⑥【外なる標準化のチェック】業務機能で例外処理がないか、へんなこだわりはないか
⑦【IT化のチェック】電子化やシステムに置き換えができないか
          
それぞれをもう少し詳しく見て行きます。

目的合致性というのは、目的が明確になっているかということとは違うということに気をつけてください。上にも書いてあるように“なぜそのプロセスが存在しているか”が明確になっていることなのです。すなわち、その会社の事業運営にとって必要不可欠のプロセスなのかどうかということです。いくら目的が明確でもその会社にとって要らないプロセスかもしれないのです。

一貫化というのは、業務がスムーズに流れるようになっているかをみていきます。途中で流れを止めているようなアクティビティやアクションが入っていないかをチェックするわけですが、本技法ではマクロワークフローが書類の流れとして連続性を担保しているので、この作法どおりにやっていけば一貫化は達成できると思います。むしろミクロのワークフローにおいて、意思決定が遅れたりしないように、メンバーの選定やロールの設定、運用ルールなどに気をつけます。

シンプル化というのは、言うまでもなく、変な迂回や分岐がないかなどをチェックします。データ確定がない書類は作らないので、それだけでもシンプルになります。

プロセスは共通化できるものは極力共通化することを心掛けます。全体のプロセス数を少なくすることは管理のしやすさにつながります。ヒト・モノ・カネの流れを分離することはこの共通化ということにつながっています。例えば、代金請求・回収プロセスというのは、様々なものの流れに対して共通のプロセスになります。

標準化には内なるものと外なるものとがあります。同じプロセスなのに営業所ごとで違っていたりしないようにというのが内なる標準化です。また、業界標準とは違った自社固有を持たないといったようなことが外なる標準化となります。

最後にIT化のチェックですが、最近はツールやデバイスもいいものが出てきていることもあり、手作業でやっているところをITに置き換えていくことは積極的に進めていくべきだと考えています。

実はこの作法自体がここにあげるチェックポイントに答えるようになっていますが、これらチェックポイントを頭の中に入れてプロセス設計をおこなっていった方がよいでしょう。またこうしたチェックはそれぞれがいろいろな局面で必要になってくるものなので、絶えず注意しながら進めていきます。

作法その11のポイント

・作法を忠実に守ること
・いつもチェックポイントを頭の中に入れて設計する


2008年6月 6日

業務プロセス設計作法 ~作法その12~

原則スイムレーンは設定しません

スイムレーンとは、組織や役割によってレーンを区切り、タスクを関連するレーンに配置するプロセスの表記法で、モデラーや業務フロー図には必ずあります。

しかしながら、本作法では原則スイムレーンは設定しないようにしています。

書類というコンポーネントを並べて作られたプロセスは、基本的には組織や部門を意識していません。なぜなら、組織や人が変わろうとも事業の営みとして必要なプロセスとして規定しているからです。

また、組織を意識すると現状肯定がベースでになり、その組織があるから、そこに人がいるから、仕事を作るということもでてきますので、業務改革しようとする場合などはない方がよいことがあります。

組織や人を意識するのはミクロワークフロー(CMS)側で、ここではメンバーの所属や関連部署などを設定していきます。

ただ必ずしもスイムレーンを書かないことばかりかというとそうでもない場合があります。

例えば、現場ヒアリングなどからプロセス抽出する場合のように、現状の仕事の流れを追いながら設計していくような場合は、スイムレーンがないとわかりにくいところが出てきますので、スイムレーンを設定した方が理解が早いかもしれません。

また、設計したプロセスのアクティビティをどこの部署でやらせたらいいのかといった組織シミュレーションには必要となります。

繰り返しますが、ここでスイムレーンの設定を推奨していないのは、この技法の特徴である組織や人という変化しやすい要素の影響はミクロワークフロー(CMS)に寄せてしまうというやり方をとっているため、マクロワークフロー側では設定の必要がないということなのです。

作法その12のポイント

・組織や人はミクロワークフロー(CMS)で規定し、マクロワークフローにはスイムレーンを設定しない
・現状分析や組織シミュレーションを行なう場合はスイムレーンを設定することがある
 

2008年6月 9日

業務プロセス設計作法 ~作法その13~

BPMSではデータを保持するための必須データだけを持ち、それ以外のデータはCMSにアーカイブします

本技法は、基幹系のデータベース(マスタ、勘定科目)ありきの前提です。もし、それがないようであれば、もちろんきちんとモデリングしてDB設計が必要になります。

BPMSはデータベースをもっていますが(例えばSavvionはORACLEを搭載しています)、そのデータベースは、業務フローのトランザクションデータ(仕掛かりデータ)を保持するためのものという考え方で、データスロットのデータは必要最小限のデータとします。

そのデータをモニターしてプロセスの制御を行なったり、パフォーマンスの解析に使ったりします。
このとき、データはデータディクショナリー(もしなかったら新たに作成した方がよいでしょう)と突合せを行い、整合性をとることが必要です。

それ以外のデータはCMSフレームワークにアーカイブされて残りますので、それらを検索したり、条件毎のフォルダーを作成したりして活用することができます。

最終的には基幹DBに終点書類で確定したデータが登録されます。仕訳を発生させるというふうに考えたらよいでしょう。

少し話が変わりますが、最近、マスタデータマネジメントシステム(MDM)という言葉を見かけるになってきました。意外とこのマスタデータを運用・管理するのは手間がかかるものであるにもかかわらず、多くは人手を介して泥臭くやっているのではないでしょうか。これはリソース管理プロセスになりますからここにもBPMを適用したらよいでしょう。

データをどうやって生成し、どうやって活用し、どうやって管理していくかを総合的な仕組みの中で考えていくことが大事になってきます。

作法13のポイント

・BPMSは必要最小限の必須データを持ちパフォーマンス管理などに使う
・それ以外のデータはCMSでアーカイブされる

2008年6月10日

業務プロセス設計作法 ~作法その14~

ビジネスルールはBPMSとCMSにコメントとして残しておき、デシジョンサポートシートにもルールを表記します

ビジネスルールはいろいろなところで出てきます。BPMSのアクティビティの順序も分岐もビジネスルールとも言えます。CMSでも議論の中でビジネスルールに従ってものごとを決めていきます。それらをファイルやリンクとして参照することになります。

また、デシジョンサポートシートというのを書きますが、そこでも意思決定のためのルールが出てきます。このように、さまざまな局面でビジネスルールが登場してきます。

ですから、短いあるいは小規模な業務プロセスを扱っているときはコメントを書いておくということでよいのですが、会社全体だとか広い範囲で見ていく場合には、統合的なビジネスルールブックを作った方がよいかもしれません。

このビジネスルールがその会社の競争優位の源泉だったりすることもありますから、リーソースデータと同じようにリポジトリーとしてきちんと管理するプロセスも持った方がよいと思います。

世の中にはルールエンジンを搭載したようなソフトウエアがありますが、そこまで使ってプロセスを管理することは少ないような気がします。それこそEXCELのとうな目に見えるデシジョンテーブルのようなものでかまわないのではないでしょうか。

作法その14のポイント

・ビジネスルールはコメントとして記述しておく
・大規模になったら統合的なルールブックとして管理する
 

2008年6月11日

業務プロセス設計作法 ~閑話休題(4)~

トップダウンアプローチとの合流

いま提示している方法論は基本的にはボトムアップアプローチになります。すなわち、AsIsのプロセスを抽出して、書類化という整理のしかたでプロセスを作って、それを動かすという方法論です。

こうしたボトムアップだけではその業務プロセスはまだ不完全です。トップダウンのアプローチを併用してこそいい業務プロセスになります。差別化を図ったり、競争優位を発揮するためには、こうしたハイブリッド型のアプローチを推奨しています。

トップダウンというのは、経営戦略あるいは事業方針のようなものから落とし込むやり方で、コンサルティングファームの得意のところで、シックスシグマだとかバランス・スコアカードなどの手法が有名であるが、それでなくとも、自社のSWOT分析を行い、CSFを導いてとかいったやり方でも出すことができます。

また、標準的なやり方でモデル化することも行なわれています。そうした中に「SCOR」(スコア)というのがあります。これはSCC(サプライチェーンカウンシル)という団体が作った、サプライチェーン記述の世界のデファクトスタンダードであり、MECE(もれず、ダブラず、網羅した)なプロセスモデルです。

このモデルは、階層化されたレベルがあり、標準ではレベル1(プロセスタイプ)、レベル2(プロセスカテゴリー)、レベル3プロセス(プロセスエレメント)までが提示されています。レベル4(アクティビティ)からは各社で落とし込むことになっています。

そして、実際にこのレベル4への落とし込みを行い物理モデル設計のためのテンプレートを作った人がいます。株式会社マネジメント&ERPインテグレーション社の渡辺和宣さんという方で400以上ものテンプレートをもっています。

先日来、この渡辺さんと何度か情報交換する機会があって、そのときにSCORのレベル3からレベル4への分解・拡張のやり方や実際のテンプレートを見せていただきました。これはかなりの労作です。そして、そのとき生じた問題点をおっしゃっていて、それは“非定型業務のIT化”だというのです。

渡辺さんの手法は、意思決定の連なりでプロセスが成り立つという考え方で、従って、ひとつひとつのアクティビティにどういう情報をきっかけとしてアクションがおき、どんな情報を参照して、結果的にどんなアウトプットを出すのかというようなことが書かれています。

この考え方というのは、書類コンポーネントと一緒の考え方になります。ですから、相性がぴったり合っていたのです。ところが、渡辺さんは、その中で、ある情報が状態遷移していく様をどうやってIT化するのかを悩んでいました。いわゆる人間系の不定形処理のところです。

さておわかりのようにここでトップダウンアプローチとボトムアップアプローチの邂逅となったのです。こうしたあいまいでゆるい非定型業務処理は情報共有の場で行なうのが適していることにひざをたたいた瞬間でもあったのです。

すなわち、上から降りてきたプロセスをここで書いている作法に則って設計していけば、レベル4から実装レベルへと落としていけることがわかったのです。渡辺さんのレベル4の粒度はかなり書類コンポーネントに近似していますので、必ずしも、書類化する必要もなく、そのアクティビティ名でコンポーネント化してもかまいません。

ということで、割りと簡単につながりますので、このハイブリッド型アプローチで少しサンプルモデルを作ろうと考えています。トップダウンアプローチのよさは、具体性は弱いが網羅性があるということとリファレンスモデルになること、またベストプラクティスの参照ということにあると思いますので、そうした要求に対しては有効な方法であると思っています。

2008年6月12日

業務プロセス設計作法 ~作法その15~

帳票は作らないようにします

システム化するとき必ずペーパレスを指向します。しかしながら、ほとんどが挫折してしまいます。仮に帳票を減らせたとしても紙は減らないのです。なぜなら画面そのものを、あるいは用意された印刷用のページなどをせっせと印刷するからです。

ですから、帳票を減らすことと紙を減らすことはちょっと次元の違う話かもしれません。ここではもちろん帳票を減らそうということです。帳票は元来帳簿と伝票のことだったのですが、今はもっと広範な意味に使われていて、システム上、紙で出力するものをすべてそういう言い方がされています。

帳票を全部やめられるかというとそれは無理で法定帳票やお客さんが絶対必要だと言っているものなどはやめるわけにはいきません。

そのほかの帳票はどうなのでしょうか。なぜそうした帳票が必要なのでしょうか。

帳票の使われ方として、まずは電子化されている業務と電子化されていない業務の橋渡しと言われます。例えば、決済のハンコを押してもらうために紙を回すといったようなことです。

次に、会議の資料とか報告書ですね。手元に置いて紙をめくりながら一覧したいということなのです。

あと意外と多いのがチェックリストの類です。定期的に膨大な量のチェックリストを印刷して机の上に載せておくという風景を見かけるでしょう。ほとんど見ないようなものも含めて積んであります。

2番目と3番目は意識して減らすことです。もはやPCは一人一台となり、プロジェクターなどのOA機器も充実しているので、極力画面を使って、会議をするとか報告書を読むとか、チェックするとかというやり方に変えていくことです。

この技法では、最初の電子化されている業務と電子化されていない業務の橋渡しとしての帳票を減らすことをめざしています。といいますか、この技法でやれば帳票が減るということなのです。確認や承認といったアクションを情報共有サイトで行なっていきますので紙による情報伝達は減るというわけです。

また、凝った帳票をつくりますが、帳票を作ることが目的でもなんでもなく、情報の伝達手段と考えたら見てくれはそんなに気にすることはないのです。

とはいえ、帳票好きの日本人はまだまだいますのでなかなか減らないかもしれませんが、そんなときはせめて帳票の電子化をしましょう。

作法その15のポイント

・法定帳票、顧客要求帳票以外は極力帳票は作らない
・作ったとしても凝ったものは作らないで電子帳票化も考える

ここでちょっとお断りを。作法その16ということで、「実作業の扱い」を予定していましたが、実作業といっても非常に多くのパターンがあります。したがって、いまの段階では、汎用的な「型」を示すのは難しいのではないかと考えています。もう少し、いろいろなケース例が出てきてから整理してみたいと思います。ということで、「業務プロセス設計作法」は一応今回で終わることにします。
 

 

About 業務プロセス設計作法

ブログ「mark-wada blog」のカテゴリ「業務プロセス設計作法」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

前のカテゴリはボトムアップ戦略立案です。

次のカテゴリは間違いだらけの業務システム開発です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type