Recently in 非定型業務のIT化 Category

これまで、プロセスの構造や機能をどんなもににするのか、それをどう設計するのかということを議論してきました。これからは設計されたプロセスをどうやって実装するのかという話になります。ここでもすごく重要なのはオペレーション発想です。オペレーションからの発想で構造を考え、それらがうまく機能するような設計をしたわけですが、それを実際に動かすプラットフォームに植えつけることをしていきます。

ここで、設計したものからプログラム仕様書に落としてコーディングするなんて考えないでくださいよ。もちろんそうやってもできますが、労多くして報い少なしです。設計のところでも見ていただけると分かると思いますが、特殊なこと、難しいことをやっているわけではありません。最初にオペレーション発想と言いましたのでもう一度「オペレーションとはいったい何をすることなのか?」をみていきましょう。何度もでてきたものです。

①ビジネス活動(プロセス)の進捗がわかること
②意思決定(データ確定・判断)に必要な参照情報を得られること
③コミュニケーションをしながら意思決定が行えること
④プロセス全体と単位意思決定の責任者が明確になっていること
⑤パフォーマンスの状況がわかり対応アクションがとれること
⑥オペレーションの結果がアーカイブされて、次に生かされること

簡単に言えば、これが実現できる仕組みと仕掛けをもったプラットフォームを持ってくればいいのです。ところが、こうした条件をすべて満たしてくれるものはないのです。じゃあ、やはりコーディングするかとは考えないでくださいよ。既成のソフトウエアを使ってできるだけ近づけるようにすべきです。

個々にはありそうですよね。例えば、①のプロセス進捗だとガントチャートなんかかもしれません。②では、検索やポップアップとかハイパーリンクですかねえ。③では掲示板やコメント、メールですね。④はアクセス権とかワークフロー、⑤はアラート、⑥はBIのようなものかもしれません。ですから、既存のソフトウエアそのものあるいはその中のひとつの機能といったものにあるわけです。

ほとんどを持っているのがBPMS(Business Process Management Suite)です。ただ、それなりの価格ですので、コストパフォーマンスを考えたときに採用できる企業は限られてくるかもしれません。では、お金をあまりかけられない、あるいは効果がわからないのでスモールスタートしたいなんていう場合はどうしたらいいのでしょうか。

BPMS以外の安価な市販ソフトを利用することになります。場合によっては組み合わせて使うことをします。安価になるということは基本的には機能不足になるわけで、そこは人力で補足することになります。自分たちの身の丈にあったコストパフォーマンスを選択することを勧めます。

さて、具体的にどんなプラットフォームがあるのでしょうか。それを見るとき、プロセスの構造を思い出してください。2段プロセスです。プロセスの進捗をみるマクロフローと単位意思決定を行うミクロフローの組み合わせになります。簡単に言うとそれぞれを何でやるかになります。それらの組み合わせ例(マクロフロー+ミクロフロー)をご紹介します。

Case-A  BPMS(メインプロセス)+BPMS(サブプロセス)
Case-B  BPMS+コミュニケーションツール(CMS、wiki、BTSなど)
Case-C  手書きあるいは進捗管理ツール+Webデータベース(デヂエ、Salesforceなど)

Case-Bのコミュニケーションツールは例えばPlone とかMTといったCMSではWebサイトの編集作業をそこで行うが、リンク情報を参照したり、承認ワークフローがあり、コメントも書き込めるので意思決定の場として使えます。その決定結果をBPMSに渡し、BPMSでプロセスを進めるといった動きになります。

Case-Cはプロセスエンジンを持たないケースです。ですからそこは人間が回すことになります。こんなことを言うとプロセスエンジンを使って自動化しないと意味がないという指摘をされそうですが、プロセスエンジンの重要性はそれほどないというのが現実です。この話はまた別途します。意思決定というのは最終的には決定された情報を登録しまうから、データベースソフトを利用します。例えば、サイボウズデヂエ(最近はKintone)のようなものが使用可能です。

少し飛躍するかもしれませんが、ARISとSAPの組み合わせでプロセス管理をする事例がありますが、この考え方も基本的には同じです。つまり、ARISでプロセス記述をしておき、そこの進捗に従って、SAPの機能と連動させるものです。

さて。この次からは具体的な実装の話になるわけですが、上記のプラットフォームのうち、サイボウズ社が昨年からデヂエの後継として売り出しているクラウド型のWebデータベース「Kintone」を使った実装についてシリーズを改めてエントリーすることにします。
  
どうやって実装するかの前に「ITを考えないで業務オペレーションを描いてみる」ことをしてみましょう。このエントリーのタイトルが「非定型業務のIT化」ですからそれを否定するような言い方で矛盾していると指摘されそうですが、単にIT化するのが目的でなくて、言外にビジネスの役に立つためのITという意味が含まれています。

つまり、ビジネスに貢献できないようなITなら入れない方がよいということです。ですから、大事なことは最初からIT化ありきではなく、ITを考えない中でその業務システムをオペレーションできるか、どんなオペレーションになるのかをみておくことも必要ではないかということです。

さて思い出してほしいのですが、業務プロセス設計でどんなことを決めたでしょうか。まずはプロセスフローを決めることをしました。そしてプロセスフローとは、アクティビティ(意思決定項目)の選定と順番というふうにしました。このことはオペレーションという観点では何を意味しているかというと、意思決定の進捗を管理することになります。

プロセスフローが決まると、確定情報、参照情報、適用業務ルール、ロール、制御変数などのアクティビティの属性を決めていきます。つまり、意思決定というのは結果としてある情報を確定することなので、その決定すべき情報とそのためにどんな参考情報やルールをみるのか、だれが決定・承認するのか、何をコントロール・監視するのかを決めることになります。

これも、オペレーション的には、迅速で質の高い意思決定を行えるように多くの有用情報を素早く取り出せ、知恵を持った人たちの助言を受けたり、上司と相談でき、また制約やコンプライアンスのチェックがなされる環境があることでしょう。こうしたことはパフォーマンスという面を考慮しなければITがあろうとなかろうと関係ない行動です。

そうなんですよね、ITがなければこうした行動、活動ができないのではなく、ITはあくまで早く、速く、多く、強く、高くなど"形容詞的"効果をもたらすものなのです。主語・述語・目的語、そして名詞・動詞はITには無関係です。では、プロセス設計されたものをITなしでのオペレーションをした場合を考えてみましょう。すなわち、コンピュータがない時代の業務です。

プロセスフローというと箱を矢印で結んで書かないといけないように思えますが、昔は"仕事の段取り"だとか、"工程表"などを紙に書いたり、黒板に書いたり、またカレンダーにマグネットを置いて管理したりしていました。有用情報は紙でキャビネットにあるバインダーに綴じられているものがほとんどです。そのページを指でめくって探したものです。他にも新聞の切り抜きをスクラップブックに貼ったりしました。マイクロフィルムというもありましたね。

コラボレーションというのも、隣のひととメール交換する現代よりもっとまともなコミュニケーションをしていたような気がします。何かあると皆が机の回りに集まって来てなんだかんだと議論しましたし、電話やFAXでやりとりもよく行われました。もちろん、契約書だってありますからちゃんとチェックしていました。期日管理なんていうのも大きな張り紙があったりしました。

こうしてみると、やっていることはいつの時代でも同じだったのです。しかし、それが効率的であるのか、迅速性がないのか、狭量的になっていないのかといった問題を抱えていたわけです。もっと早くやりたい、もっと多くのことを知りたい、もっと高度にしたいといった欲求不満を解消してあげる必要が生じたのです。

例えば、プロセス管理をホワイトボードでやると何が問題なのかというと、ホワイトボードに書ける情報量が少ないこと、書いてあることを手元で見られないあるいは遠隔地と共有化できないといった問題が出てきます。同じように、いつも紙をキャビネットから取り出してめくるのは嫌だなとか、書き写す手間が大変だなとか、情報を得るのに役所や図書館までいかなくてはとなるのです。

さて、もうおわかりかと思いますが、そういった欲求を満たしてあげるものとしてITが存在しています。この領分ではコンピュータが登場してからずいぶんと大きな貢献をしていると思います。取得する情報の量と速さはとてつもなく多くそして速くなっています。ただ、だからといってやみくもにITを導入すればいいというのではなく、身の丈にあった導入をはかるべきだと言っています。

ITがなくてもやってきたわけですから、それほど多くの情報量が必要でない会社、簡単なプロセスしかない会社は無理にIT化しなくても人間が介在することでも十分できるならそれでもよいと思う。つまり、人間とITがうまく役割分担して、ベターな仕組みを作ればよいのです。こうして考えると、業務システムをプログラミングして自動化を図るというアプローチが何だかおかしく思えてきませんか。
  
前回は、業務プロセス設計が肝であるという話をしました。普通はVモデルのような開発工程があります。要求分析-基本設計-機能設計-詳細設計があってコーディングをして、そのあとそれぞれのレベルに対応した単体テスト-総合テスト-システムテスト-受け入れテストというわけです。では、業務プロセス設計というのは、どこに相当するのでしょうか。

どうも、このモデルとはマッチしませんね。それもそのはずです。コードを書かないからです。Vモデルは谷の底がコーディングです。つまり、コードを書くために一連の設計があってテストがあるわけで、そのコーディングがないのだから適用できないのです。そもそも、Vモデルはソフトウエア製品の開発に対してのものであって、それを業務システム開発に当てはめるのが間違っています。

というわけで、非定型業務で業務プロセスの設計がちゃんとできたらすぐに受け入れテストして運用ができるのです。なぜそんなことができるのかを考えていきましょう。というか、もしプログラマーがいなくて、あるいはお金がなくて開発費用が出せないといった制約の中で業務システムを作ろうとしたらあなただったらどうしますか。あきらめますか?

ユーザの人たちはどんなプロセスで仕事をしたい、業務を回したいという要求を出してくれたわけだから、その通りに動くものをつくればよいと思ってください。そこから余計な機能を引っ張り出すことも、凝った作りにすることも必要ありません。そして、何も全部ITでやれなくてもいいわけで、できなかったら人間がやればいいかもしれない。

ここのところが非常に重要なところで、業務システムの構築(ソフトウエアとかいT製品ではありませんよ。間違わないように)は、けっしてITシステムを構築しなければいけないなんて誰も言っていないということです。SIerやITコンサルのひとたちが言っているだけでしょ。つまり、プロセス設計で定義したことを実現できるものをどこからか探してきて組みあげればよいのです。

もちろん、それだけではできない場合があります。例えばシステム間の連携なんてひょっとしたらコードを書かなければいけないケースもあると思います。だが、それは仕方なしにそうするのであって、最初からコードを書くために設計してはいけません。データ連携にしても近頃はコードレスでマッパーで設定さえすればできるものも出てきています。

そうなんですね。いまここで言っていることは昔はなかなか難しかったのは確かですが、最近はいいソフトウエア部品がいっぱいあります。ですから、プロセス設計で定義し機能に合致した、あるいは機能は落ちるけど何とかできそうだという市販の汎用的なソフトウエアを選択してきて、それらを組み合わせて構築することを勧めているのです。
  

前回は、Howということでどのようにして設計して実装していくかについてとっかかりの考え方について議論しました。そこでは、プロセス中心、プロセス先行でみていくことが大切だということを言いました。今回は、設計のところを具体的にどのように進めるかについて考えていきましょう。

このエントリーのタイトルが「非定型業務のIT化」ですので、非定型業務であるがゆえの特徴をまず考えてみます。IT化のための設計というとどうしてもプログラムを書くためとか、パッケージを適用するための設計といったものになりがちです。いわゆる「要件定義」という行為が設計だと思ってしまうことがあります。ここはよく考えなくてはいけない問題で、一生懸命ユーザの人が業務上の要求を出しても、結局はITのための設計に行ってしまうので断絶が生じてしまうことがよくあります。

使う側の人たちが欲しているのはうまく仕事をする、円滑に業務を回すための仕組みと仕掛けを作ってくれと要望しているのであるから、極端なことを言えばどんなプログラムを書こうと、どんなソフトウエアを使おうともそれが実現できればいいのである。つまり、だいぶ前「Whatはオペレーションから発想する」に書いたようなWhatをどうやって作るのかなのである。もう一度、オペレーションプラットフォームが持つべき要件を思い出してほしい。

①ビジネス活動(プロセス)の進捗がわかること
②意思決定(データ確定・判断)に必要な参照情報を得られること
③コミュニケーションをしながら意思決定が行えること
④プロセス全体と単位意思決定の責任者が明確になっていること
⑤パフォーマンスの状況がわかり対応アクションがとれること
⑥オペレーションの結果がアーカイブされて、次に生かされること

これらの要件はユーザの人たちが実際にビジネスの現場でやっていることを表現しています。ですからこれらを満足させるための設計はいかにあるべきかが大切なのです。そして、ここにはプログラムがどうの、ソフトウエアがどうのということは出てきません。非定型業務のIT化にはこのレベル感が非常に重要になってきます。

いまの要件定義といわれているようなことはこの一段下のレベルのことを言っています。つまり、定型的な業務に落ちてしまっています。どんな画面や帳票でとか、ロジックはどうするのかとか、バリデーションはこうだとか、それって"非定型業務の結果を登録する定型化された業務"でしょう。

ちょっと話はそれますが、設計で機能要求とか非機能要求、あるいは外部設計とか内部設計といった言い方がありますが、意味は何となくわかるのですが、なぜ分ける必要があるのかとか、システムを使う人が理解できるのだろうかと思ってしまう。ましておや、これからクラウドの時代にはそぐわないだろう。

ということで、設計で大事なのは業務プロセス設計になります。先ほど提示したオペレーションプラットフォームの持つべき要件を満足させるために業務プロセス設計で決めることは何でしょうか。まずは、プロセスフローを決めることになります。ではそのプロセスフローとは何かですが、アクティビティ(意思決定項目)の選定と順番になります。ただ、順番は厳密なものではありませんのでだいたいの流れでかまいません。

それが決まると、アクティビティの属性を決めて行きます。意思決定をするために定義しておかなければいけない項目です。それは、確定情報(データ、判断、文書)、参照情報(事実情報、判断情報、制約情報)、適用業務ルール、ロール(権限、参加者、承認者)、制御変数(プロセスメトリクス)となります。実際には、これらの基本情報に付帯する情報も必要に応じて定義しておきます。非定型業務の設計はこの程度でかまわないのです。緩すぎないかと思うかもしれませんが、要するに非定型なのですから定型化してはいけないのです。
 

さて、これまではWhat を考えてきましたが、ここからはHowについて検討していきましょう。ビジネスの貢献する仕組みと仕掛け、すなわちプロセスの構造とか機能をどんなものにするのかから、それをどうやって設計し、実装していくかという問題です。

そこで重要なコンセプトを思い出してください。「Function/Data Oriented」「Development Excellence」「Independent Work」から「Process Oriented」「Operation Excellence」「Collaborative Work」にシフトしましょうということを提案しました。この新しいコンセプトに沿ったHowを考えて行きます。ただ、「Development Excellence」から「Operation Excellence」だから、開発はあまり重要ではないと思わないでください。重点が移動したのであって、まだその重要性は変わりません。

Howの最初はプロセス設計になりますが、そこで大事なのは「プロセス中心アプローチ」という考え方を理解することです。設計ではプロセス中心というよりもプロセス先行といった方がわかりやすいと思います。言葉のとおり、まずプロセスを作っておいてそこにそれ以外の要素を定義していくというやり方です。

こういうことを言うとそれはデータ中心でやるべきだとかという声が聞こえてきます。なるほどDOA(Data Oriented Approach)ですね。以前にも何回かこのブログでも言及しましたが、プロセス中心かデータ中心のどっちを取るのかという議論ではなく、向き不向きがあるので使い分けることが大切です。

つまり、データでマスタのようなリソース系のデータ(名詞形で表現できる)はデータ中心でやるべきです。リソース系というのは、企業活動の原動力になるわけですから、個々のプロセスには関係なく前もって決めておくものです。例えば、従業員データとか取引先マスタといったものは、それがビジネスを動かすためにあるというか、手持ちのリソースを使ってどんなビジネスをするのかが決まったりします。しかも全社に渡って使われるものですから、あらかじめデータベースを設計しておくことをします。

一方、トランザクションから発生するようなイベント系のデータ(動詞形で表現できる)は、プロセス中心でやるべきであると主張しています。イベントデータはプロセスがあってこそ存在するわけですから、まずは企業活動の一部としてどんなプロセスがあって、そこで生成するデータは何かというアプローチになるわけです。

例えば、受注データというイベントデータは、受注プロセスから出てきますし、売上データも同じように販売プロセスと対になっています。取引先データは購買プロセスから出てきませんよね。ですから、理想的にはプロセスを正規化しておけばイベントデータも正規化されることになります。このことは業務の標準化や共通化という視点からも重要なことだと思います。

ということで、データ中心ではプロセス設計はかなり難しくなりますので、プロセス先行設計を勧めています。まず最初に業務の流れを中心としたプロセスを描き、そこに必要なデータは何か、使うユーザインターフェースはどんなものにするのか、どんな業務ルールに従うのか、責任の所在はどこにあるのか、何を測定してコントロールするのかといったことを設計、定義していくのです。

このやり方は、実はユーザの人たちにとってもなじみやすいこともあります。なぜならば、業務の流れとか、仕事の段取りといったようなことって結局プロセスだよねということです。データフロー図(DFD)を追っても、ER図をながめてもユーザの人はなかなか理解できないのではないでしょうか。
 

前回は、業務プロセスの骨格ということで、始点が依頼を受付けることで、中間点として意思決定というアクティビティをつなげて作業をおこない終点である報告・登録で終えるというものを提示した。今回はそれをもう少し骨組みの中味を探ってみることにします。

非定型業務をIT化するときこのプロセスの構造ということが非常に重要になります。つまり、非定型といってもはなから非定型ではなく階層化された中で、あるレベルになると非定型になるというものだからです。その一歩手前の定型化された構造をきちんと設計しモデル化することが大事なのです。

さて、そのプロセスの基本構造ですが、前回の骨格をプロセス化すると、依頼受付―単位意思決定の連鎖―作業―報告・登録となります。次に検討しなくてはいけないのが、単位意思決定の中味はどんなことをすることなのかになります。実はこの中もプロセスになっています。ですので、最初の方がマクロフローで、意思決定のところがミクロフローということがいえます。

つまりこの2段プロセスが基本構造の重要な考え方となります。マクロフローのレベルではほぼ定型的な動きになりますが、ミクロフローでは非定型的、すなわち行ったり来たり、ケースバイケース、人間の判断、調整といった決まりきった動きではないことが多くなります。ですから、順序が定型化されたものとして構造化できないのでこれ以上分解をしない方がよいということになります。

皆さんが普段やられている仕事や組織としての業務をごらんになればわかると思いますが、おおまかな流れは決まっていますが、細かいところでは決まりきったものってそう多くはないと思います。そうですよね、もしそうならば、派遣社員にまかせればいいし、中国へアウトソーシングすればいいわけです。非定型業務こそが差別化や競争優位の源泉であるのです。そんなところって単純なITではできるわけではないということがわかると思います。

さて、それでは意思決定プロセスというのはどうなっているのかですが、前回サイモンの意思決定プロセスということを提示しました。具体的に考えてみましょう。最初の情報活動とは意思決定に必要となる情報を収集することです。次の設計活動は代替案の探索・代替案の評価、つまり起案したものを検討・評価してこれでいこうという最終案を提示し、選択活動では代替案の選択、つまり意思決定と承認を行うわけです。

こうした活動を行う場合、前に言ったように定型的ではありませんから、手順を自動化するようなIT化はできません。ですから簡単に言うと"質の高い意思決定を早くできるような環境を提供する"ことが求められるのです。ではそうした環境とはいったいどんなものなのでしょうか。

それは、情報共有・コミュニケーションと有用な情報サービスの取得による意思決定ができる場ではないでしょうか。非定型業務では、チーム間や外部とでコミュニケーションをとりながら、調整や相談をすることをします。また、それぞれの活動で情報を必要としています。例えば、情報活動では事実情報、設計活動では判断情報、選択活動では制約情報といった種類のものがあると意思決定の質は上がります。

結局、プロセス構造は依頼を受付けて答えるまでのマクロフローとそこにあるミクロフローである単位意思決定を行う情報共有・コミュニケーションの場と情報サービスを受けられる仕組みがプロセス基本構造となるのです。
 

前回は、オペレーションプラットフォームが持つべき6つの要件について考えてみました。今回からは、こうした要件を満たしてくれるプロセスの構造について考えていきます。こうして、オペレーションから発想したプロセス設計が大事なってきます。

業務オペレーションはいったい何をすることなのかというと超簡単に言うと、顧客の依頼あるいはサービス要求に答えることです。そして、その答えを作るのにはいくつかの意思決定を行うのが普通です。そうした意思決定の連鎖つまり答えを作っていく過程をプロセスと規定しています。ここで顧客と言いましたが、狭い意味のお客さんだけではなくて、取引先、サプライヤー、経営者、従業員といったところからも依頼がきますので、それらを含めた広い意味での顧客を想定しています。

プロセスは大まかに言うと、始点と終点があってその間にアクティビティとよばれるものがある構造になるわけです。アクティビティはだいたいは単位意思決定というふうに考えてもらってかまいません。ではまずプロセスの出発点すなわち始点は何なのでしょうか。それは最初にいったように依頼が来てから始まるわけですから、「依頼を受付ける」ことが最初になります。

この場合の依頼の来方は様々です。電話やFAX、メールなんていうこともありますし、注文書とか依頼書とかいった紙で来る場合もあります。最近ではEDIみたいなシステム的な依頼形態もあります。しかしいずれも一旦受付けてその依頼内容を確認することをします。非定型業務だと必ずしますが、定型業務だとそのままエスカレーションすることもあります。

依頼を受付けるとその依頼項目に従って答えを作ることになります。答えを作るのが意思決定でこれも実はプロセスでもあります。意思決定プロセスというとH・A・サイモンのものが有名ですが、もうそのままです。サイモンの意思決定プロセスは、情報活動、設計活動、選択活動、検討活動の4つから成り立っています。

意思決定に必要となる情報を収集(情報活動)して、代替案の探索・代替案の評価(設計活動)を行い、代替案の選択(選択活動)し、実施し、その結果をフィードバック(検討活動)することです。日常のプロセス管理では初めの3つが重要な要素となります。

こうして、意思決定を行って、答えを作るのに何か作業がいるようなら、作業というアクティビティが入ってきます。例えば、見積を出すのに見積書作成という作業があってそれが入ることがありますし、修理依頼がきたら実際に修理作業を行って修理調製品として返すなんてこともあります。

作業が終わって、依頼に対する回答がそろうとそれを依頼元へ返事を返さなくてはいけませんし、結果をデータベースに登録しなくてはいけません。このアクティビティが終点となります。報告・登録を行ってこのプロセスが完了するわけです。こうした構造がプロセスの骨格となります。
  

前回は、Whatすなわちプロセスの仕組みはオペレーションから発想すべきという提案をしました。このプロセスオペレーションというのはおおかたは非定型業務になります。定型の場合は自動化できるので人間によるオペレーションという範疇からは外れるからです。ITに任せてしまうようなプロセスではなく、人間が介在して扱うプロセスは非定型でそのオペレーションを適切に行うためにはどんな道具が必要であるのかという発想です。

このことは何回も繰り返しますが、システムは使ってナンボ、使われてナンボだからです。決して作ってナンボではありません。従来のシステム開発の発想が作るところが主眼になっていて、それがどう使われようとも、いやもっときつい言い方をすると使われなくてもかまわないとういうスタンスだったように思います。そこを逆転させる必要があるわけで、作ったものを使ってもらうではなく、使われるものしか作らないということになります。

こうした発想になると、ITシステムというよりオペレーションプラットフォームをどうするか、どんなものの上で業務を遂行するのかというアプローチになります。そうしたプラットフォームが持つべき要件にはいったいどんなものあるのでしょうか。こんなものがあったら、こんなことができたらいいなあというものです。次のように考えています。

①ビジネス活動(プロセス)の進捗がわかること
②意思決定(データ確定・判断)に必要な参照情報を得られること
③コミュニケーションをしながら意思決定が行えること
④プロセス全体と単位意思決定の責任者が明確になっていること
⑤パフォーマンスの状況がわかり対応アクションがとれること
⑥オペレーションの結果がアーカイブされて、次に生かされること

このことは、別にITシステムだからというわけではないのがお分かりだと思います。ITがなかった昔から行われていました。例えば、進捗管理は黒板や模造紙に書いて眺めていたり、電話や机の前の会話で意思疎通を図ってしたし、参照情報はキャビネットのファイルを拡げたり、新聞のスクラップブックを見たりしていました。責任者にしても、昔の方がちゃんとしていたかもしれないし、対応アクションも現場の課長が的確に指示し早かったかもしれない。記録も紙だったけど報告書を書いていた。

つまり、何を言いたいかと言うと、ITに関係なく業務プロセス、仕事を効率的にかつ質の高いものにできるなら、そこにITを入れていくという心構えが大切であるということです。何も、ITで今までと違う特別なことをするわけではなく、ITを使うことで早くできたり、多くの選択肢から選べたり、助言や指導が受けやすかったりできるようになるということなのです。

ただ、ここで忘れてはいけないのが、今までと違う特別なことをするわけではないと言いましたが、それはあくまでITのレベルの話なのであって、業務プロセスのところでは、従来と違ったものを設計していくことが大事であるということです。こんなことを言うと、インターネットや、最近のスマートフォンやiPADの登場で仕事のやり方が変わりじゃないかと突っ込まれそうですが、確かにビジネスモデルが変わって、プロセスの変更もあると思いますが、あくまでHow toのところの話が主なような気がします。

結局大事なのは、ビジネスに貢献するための業務プロセスの仕組みと仕掛けの設計のところで、ここが肝だということなのです。それをはき違えるとやれクラウドだiPADだとか、ビックデータだとかが出てくると右往左往してしまうのです。そうしたデバイスやテクノロジーを有効に使えるようなプロセス設計ができていないといくらハイテクを入れても猫に小判システムができるだけで意味がないと言いたいのです。
 

前回は、Whatすなわちプロセスの仕組みを考えるとき既成概念から離れて新しいコンセプトのもとで考察すべきだとし、「Process Oriented」」「Operation Excellence」「Collaborative Work」というコンセプトを提示した。この考え方をベースにWhatをみていきます。

なぜ、オペレーションから発想すべきなのでしょうか。ここはなかなか気がつかないのですが、非常に重要なことです。つまり、上にあげたコンセプトの二番目にあるOperation Excellenceというのは、従来のように作ったら終わりではなくオペレーションして成果を上げて初めて終わりになるということを意味しています。ですから、成果をあげられるものでなくては使わないぞというユーザの意思であり、使ってもらってこそのシステムの価値が出るのです。

もう何度も言っていますが、作ってナンボではなくて使ってナンボなのです。使ってナンボと言っても単に使うだけではなく、結果的に目標を達成して事業成果に結び付かないと意味がありません。従って、オペレーションという中には、コントロールという意味合いも含んでいることを忘れてはいけません。コントロールというのは、制御対象の測定値が目標から乖離していた場合、それを近づけようとして手を打つことです。

プロセスマネジメントの重要な要素にこのコントロールという概念があることも忘れてはいけません。というかある意味肝のところでもあります。戦略目標からKGIとかKPIといった定量的な指標に落ちてきて、さらにプロセスメトリクスというようなオペレーションレベルの指標となります。こうして、定性的であいまいな指標ではなく、具体的な目標値をコントロールすることで成果を出すことが求められているわけです。

それと、コントロールできるかどうかは、測定値をきちんとモニタリングできているのかも大事になってきます。当然正しく、そして所定のタイミングでセンシングできないと適切なレスポンスが返せないのである。このセンス&レスポンスが不十分だと、手を打つタイミングを逃したり、危険を察知するのが遅れたりする。化学プロセスなどはここが命でうまくいかないと事故を起こしたりしてしまいます。ビジネスプロセスも基本的には同じ考え方でみていくべきだと思います。

以上のように、正確なモニタリングにより、適正なコントロールが行われ、結果的に効率的なオペレーションが維持されている状態が必要があって、それを実現させるために使う道具は何かという話です。よくそれはプラントのように自動制御でやればよいのではと言われます。

しかし、実は化学プランスのようなものとビジネスプロセスの違いがあって、何が違うかというと、科学的、論理的なのか、そうでないのかということです。ビジネスプロセスは、人間の判断という要素がたっぷり入りこんでいますので、非科学的で非論理的な部分が多いからです。ですから、多くのビジネスプロセスには、自動化されたシステムではなく、人間が使う道具が欲しいのです。
  

前回は、WhatはHowに優先するということが非常に大事であるという指摘をした。悪いWhatをいくら良いHowで作っても意味がないのである。それなのに、巷ではHowの話ばかりしていて肝心のWhatの議論がほとんどない。30年間ずっと変わらないWhatの疲労がきているのにもかかわらず。

さて、Whatとは何か。まずは少し抽象的ですが、概念を言おうと思います。「Whatとは、ビジネスの貢献する仕組みと仕掛け」としてみました。仕組みというのは別の言葉で言うと構造ですね。おなじく仕掛けは機能とでも言ったらいいかもしれません。要するに、単なる箱ではなく、仕掛けをもった、機能を具備した構造体を指しています。

ここで具体的な中味を議論する前に、コンセプトレベルでもこれまでと違った見方をする必要があります。小手先だけ変えるのでは本質的な変革はできません。これはおおげさに言えばパラダイムの転換ということです。では、これまでの「ものの見方や捉え方」はどうであってこれからどう変えるべきなのでしょうか。

システム開発あるいは業務システムの世界での従来の考え方の特徴を3つあげると、「Function/Data Oriented」「Development Excellence」「Independent Work」だと考えています。最初のFunction/Data Orientedというのは、システムを作る時に画面から、あるいはデータから考えるということです。もちろん、データ、機能、プロセスのどれもが必要なのですが、どれを中心に、あるいは先行してアプローチするかということで、これまでは画面やデータを中心にというやりかたが多かったのです。

Development Excellenceというのは、開発が目的化しているという意味になります。システム屋さんに開発してもらったはいいが、プロジェクトが終わるとさっさと引き上げてしまい、どんなふうに使われているかは無関心ということが多いと思います。要するに作ってナンボの世界なのである。

後のIndependent Workというのは、作られたシステムは、個人が画面に向かってデータを打つ、帳票を出すためのものになっていることを言っている。コンピュータは決まった時間に決まったフォーマットでデータを入れろと命令してくる。それに個人が一生懸命答えているという姿が浮かんできますよね。

どうもこれではいけないと感じていると思うのですが、ではどう「ものの見方や捉え方」を変えるのでしょうか。上に挙げた3つに対しての新しいコンセプトは、「Process Oriented」「Operation Excellence」「Collaborative Work」です。画面やデータに対してプロセスを中心に考えましょうということ、作ってナンボではなく使ってナンボなんですよということ、個人の作業ではなくチームとして情報共有の場で仕事しようよという意味になります。

新しいコンセプトと言いながらふと考えたのは、別に新しいことではなく昔から業務や仕事の場では当たり前のことなのではないかということである。だから、システムの世界が現実から乖離していたという言い方もできる。なぜもっと素直に現場で行われていることを写像しなかったのかと思うのであるが、これは別のところで書く。

とは言え、業務システムにとってはコンセプト変えることであり、着手点もHowではなくてまずはあるべきWhatの姿を考えて見ようというのが大切な態度だと思うのである。
  

About this Archive

This page is an archive of recent entries in the 非定型業務のIT化 category.

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

Pages

Powered by Movable Type 4.34-en