ちょっと前まで「業務プロセス設計作法」を連載していましたが、この設計法は従来の考え方とだいぶ違うと思っています。それは単にメソッドとしての違いというわけではなく、企業における人とITの関係が変化したということなのです。働き方が変わったのであり、ITの使い方が変わってくることを意味しています。

そこで今日からこのあたりについて少しずつ書いていこうと思います。今までもずいぶんとそれらしいことは書いてきましたが、繰り返しになる部分があるかもしれませんがもう一度おさらいしてみることにします。

それでは、人とITの関係がどう変わるのでしょうか？

結論的なことから先に言いますと、「ITに使われる」ことから「ITを使う」ことへの変化であると言うことができます。ええ、そんなことはすでにやられているから、今さら何を言うのという反論が聞こえてきそうですが、そうでしょうか。

企業の情報システムにおけるこれまでの主役はITであって、人間はITに使われていたのです。そのあたりを少し具体的にみていきます。

もともと企業情報システムの成り立ちは、「電子計算機」を使って会計処理や給与計算をすることであったと思います。そして、当時はその「電子計算機」は高価で、しかも使える端末の数も限られていたので一部の人たちだけが利用していました。

こういう状態では、人とITの関係はどうなっていたでしょうか。使い方としては、生産量だとか販売量や購買量などをコンピュータに向かってせっせと登録していました。コンピュータは決まった時間までに、決まったフォーマットで、決まった操作で打ち込むことを人間に命令していたわけです。

そして計算処理の手段がどんどんコンピュータに移っていくと、ますますコンピュータの言いなりに人間がデータ入力を行なっていくようになりました。

だから、一部の人は腹が立ったものだから、本来自分で打たなくてはいけないデータを事務の女の子にパスワードを教えて代りに打たしたのです。

この関係って今のようにERPや業務パッケージが導入されてもやっていることは昔とあまり変わっていないように見えます。相変わらず、データをメモして派遣の女の子に「このデータ、ERPに登録しておいてよ」と言っているのではないでしょうか。

この関係を逆転させることがこれからの企業情報システムの大きな課題であると思っています。

すなわち、ITが主役の企業情報システムを人が主役となれるかたちに変えることが求められているのです。それができてこそ、業務プロセスの可視化であったり、内部統制対応だったりするわけです。ITに使われたままでは、自分たちの意思を反映する仕組みとはなり得ないのである。自分たちの意のままに動くシステムこそビジネスに貢献できるものになるのです。

次回からもう少し掘り下げながら、どうやってそれを実現していくのかといった議論に持って行きたいと思います。
　

業務システムを考える場合、よくあるのはコンピュータでやれることから考えてしまうことです。パッケージを使っても、スクラッチで開発しても同じようにパッケージの機能がこうだからとか、プログラム的にはこうした方がいいよなといった思いが先にでてしまうことがあります。

前回にも言ったように人が主体的にITを使うようにならなければいけないと考えたとき、まずは自分たちの業務プロセスはどうなっているのか、どうしたらいいのか、自分たちの仕事は何をすることなのかといったことを優先して見ていくことが求められます。

これは当たり前のことですが、ついシステム化という風に考えてしまうと順番が逆になってしまいます。コンピュータシステムを作るのではなく、業務システムを作るのですから、やはり業務プロセスから入らなくてはいけません。

これまでは、どちらかというとシステムの枠組みにプロセスを合わせるかたちが多かったのではないでしょうか。特にERPなどは無理やりそれに合わせるというやり方になったりもします。そうではなくて、これからは自社のプロセスにシステムを合わせる方向に舵を切らないといけません。

なぜかというと、業務や仕事というのはあくまで人間が主体でやるものです。人間が判断し、処理し、決定し、改善していくものでしょう。こうしたことはコンピュータではできませんし、そこに自社の個性があるわけで、「企業は人なり」という意味はこういうことでもあると思います。

そう考えると、そこで働く人たちが気持ちよく、そして能力を最大に発揮して、さらにその人たちが成長していけるような仕事の仕組みを作ることがもっとも大事なことであると思うのです。そういうプロセスをまずつくることです。

そして、それらは人間系の業務とIT系の業務がほどよく調和されたものであるべきです。従って、まずはITは関係なく自社の業務プロセスを書き出すことです。そこで、ITに任すところはITに、そうでないところは人間に任せるというシステムの構築が必要なのです。

自分たちの意のままになる業務プロセスであり業務システムにしなくてはいけません。今までのように、実際に仕事に使っている人が、どうやって動いているのか、何を処理しているのか、“コンピュータに聞いてみなくてはわからない”というようなことをなくしていかなくてはいけません。

そうなれば、人がITを使うという風に主役の交替を実現できるのです。それでこそ、いつも言っているようにコントロール＆オペレーションが可能となります。
　

さて前回、ITに任すところはITに、そうでないところは人間にということを言いましたが、ITに任せられないところはどこでしょうか。あるいは逆にITに任すものは何なのかです。コンピュータはあくまで論理演算の世界だから、セオリーがあるプロセスや機能はITに預けていけます。

ですから、非セオリー的なものがITではできないことになります。それは、人間が絡むところです。これは恣意的だし、人によってはやることや判断が変わってきます。すごくあいまいなところです。しかしながら、こうした人間的なプロセスは非常に多くの場面に登場してきます。ひとりの人間の仕事だけでなく、複数の人間が絡み合ったものまで無数の形態があります。

そして、これまではこの人間系の非定型的な業務処理はシステム範囲外に置かれていました。ここでITあるいはIT化といった場合、何を意味するかを少し考えてみます。

そこには二つの段階があるように思います。業務の処理そのものをITに任すことと人間が業務処理あるいは意思決定をするための支援情報や場の提供をITが行なうというものがあるように思います。

これまではどちらかというと前者の業務処理をITにやってもらうという意識が強かったように思います。後者の場合もないことはないのですが、どうも個人的な情報処理に対して存在していたように感じます。

例えば、メールやグループウエアというようなものがそれにあたると思いますが、あくまで個人の生産性であったわけで、基幹業務に近いところではなかなか利用されてはいませんでした。

ですから、基幹業務のところのIT化は、人間が業務処理あるいは意思決定をするための支援情報や場の提供という面では、あまりやられていませんでした。

しかし、トータルの生産性という意味ではコンピュータの処理時間は微々たるもので、そのコンピュータにデータを登録するための時間と出て生きた結果を解析するための時間が生産性を決めています。そこのコンピュータ（情報システム）の前後の業務のIT化が非常に重要になってくるわけです。

ところが、この領域はあいまいで不定形だからIT化が困難だったのです。そこでよーく考えてみると、この世界は決まった順序で情報が流れるとか、決まったルールどおりに動くとかではなく、情報があっち行ったりこっち行ったりしますし、決まったと思ったらまた戻るとか、根回しがいるとか、そんなプロセスですから、いわゆる逐次的なプロセスということではなく情報交換の広場、情報共有空間と呼んだ方がいいかもしれませんが、そうした広場なり空間をITで作ってやることが求められているのです。

こうした仕事の進め方は昔も今も基本は変わらないのであって、昔は電話やFAX、または机に集まっておしゃべり、黒板に絵や字を書いて議論して、そうしてものごとを決めていたのである。それが今やITを使って様々なことができるようになったのです。

例えば、SNS、ブログ、Wikiなどなどがそうです。そうなんです、昔のワイワイガヤガヤの世界を基幹業務システムの中にも組み入れることを提案しているのです。これらは既にWeb系の開発などでは当然のように採用された仕掛けなのであって、珍しいわけでははないので、いまの若い人たちのリテラシーでは軽く使いこなすことができると思うのです。
　

今回は、企業の組織の面から業務プロセスを見ていきます。

いまは組織がフラット化して、昔のように社長―副社長―担当役員―事業部長―部長―次長―課長―係長－班長なんていう大ピラミッド型ヒエラルキーはないと思いますが、それでも階層化はされているでしょう。

そうしたそれぞれの階層でプロセスのどこに責任を持たされているのでしょうか。また、そうした考え方で業務システム（業務パッケージ）はできているのでしょうか。

そこは多分はっきりしていなのではないでしょうか。

まず、企業情報システムの受益者はだれでしょうか。会社には、経営者、部門長、グループリーダ（課長）、担当者ぐらいにざっくりと分類できると思います。中小企業だと社長が部門長を兼ねたりしているでしょう。

社長というお仕事はそれほど業務システムを必要とはしません。逐一自社のビジネスの状況を見て経営するわけではありません。まずはそれぞれの事業の責任者に任せます。

そして、事業の責任者は自分の事業がスムーズに効率的に流れていることに責任を持ちます。しかしながら、作業局面での意思決定まではその下のグループリーダに任せることになります。担当者はグループの責任者が適切な意思決定ができるように情報を提供する責任があります。

こうして、現場の作業レベルから事業のマネジメントレベルまでそれぞれの段階で負っている責任の種類とその責任の所在が決まっています。ところが、そうしたことが判然としたシステム構造になっているでしょうか。確かに、承認権限を与えますからあたかもできているように思いますが、システムの構造としてそうなっているかは別の問題です。

上長が承認してデータ登録するというようなことは何となくわかると思いますが、グループリーダや事業部長が自分の責任となる業務プロセスを掌中に収めているでしょうか。

具体的に見ていくと、例えばある製品のサプライチェーン全体のプロセスが事業部長が見て、その中の出荷プロセスは、出荷業務グループの長が見ているというイメージになります。おそらく、そういう感覚ではなく、指定された入力を行なうこと、システムがアウトプットを出したことだけで見ているような気がします。

そこを変えていくには、グループリーダには意思決定のための情報共有の場、事業部長には業務プロセスのオペレーショナルなモニターの提供が必要になるのです。

そして、それぞれに特徴があって、作業レベルでは参加型の仕組みで絶えず情報が行き交いそこで生まれた集合知により意思決定の質とスピードが上がることです。業務プロセスでは人間系を排除したアクティビティを組み合わせることでドライで論理的なプロセスにすることです。

繰り返しますが、グループリーダは情報共有の場で意思決定の責任を負い、そこで決まったことをプロセスとして回し、そのプロセスが機能しているかどうかを部門長が責任を負うというかたちになります。これが、業務プロセスをオペレーションする姿です。
　

ちょっと前に紹介した「不機嫌な職場」（講談社現代新書）という本では、いま職場がおかしくなっていて、要するに、関わらない、協力しないという関係になっていると書いてある。閉じた働き方、閉じた関係になり、タコツボ化がおきているという。

こうしたことは企業活動自体にも大きな影響を及ぼしていて、一つは生産性の低下である。協力しあえばスピーディに判断・行動できるのに、お互い押し付けあったり、知らんぷりして時間がかかってしまう。

もうひとつは品質の低下である。協力しあえないことで互いのミスが見落とされたり、問題を指摘しあわないといったことがおき、組織の自浄作用も失っていくという。

こうした状況を変えるためには、お互いがいつも知恵を出しあい、協力しあえる環境作りが大事である。
それと、これまでの日本の企業の特徴であったいい意味での「あいまいさ」が消えていっているような気がする。

これは、あうんの呼吸とか行間を読むとか察しろとかいうことでもあるが、良し悪しはもちろんあるのだが、あまりにも型にはまったことしかやらせない、あるいは決まったことしかやらないといった状況になってやしないだろうか。

一人一人の工夫や知恵で生産性や品質を上げてきたのがかつての日本の製造業だったはずだ。こうした個人やグループの裁量を信じるような環境も必要になるだろう。

ですから、これからは日本の職場に合わないような米国型成果主義をすて（まったく捨てろというわけではない。成果を正当に評価するこことは大事なことではある。）、みんなが協力し合って、それぞれが能力を発揮し、組織としても最大の力が出せる仕掛けが要るようになっている。

さて、こうした要請に対してITはどう対応しているのだろうか。ここのところがものすごく重要なところで、これまでのIT（ここでは業務システムのことをさす）は何も提供できていないと思う。むしろ、タコツボ化のシステムを作ってきたのではないだろうか。職場のみんなが協力し合い、個人の知恵を出し、質の高い仕事ができるような仕組みであっただろうか。

グループウエアやナレッジマネジメントの仕組みを作っているじゃないかと言う人がいると思うが、ここで言っているのは業務システムのことである。受注業務を営業の人、受注センターの人、製造の人、デリバリーの人などが、協力しあいながら、オーダーを受領するといったことである。

おそらくこうしたコラボレーション的な仕組みにはなっていないものがほとんどでしょう。基本的に、業務システムはシステムに担当がデータを登録して上長が承認して、その結果をまた違う部署の人がシステムを起動して見てから業務を行なうというスタイルではないだろうか。

これは、ITを意識しないで仕事を考えた場合、システムはその仕事の流れ、あるいは流し方と同じようになっているでしょうか。ひょっとしたら、ITがあるがために本来流れるべきフローとは違った動きをさせられているということもありえるのだ。

ここを変えていかなくてはいけない。どうするかというと、あいまいな処理を情報共有の場で実現するミクロワークフローと会社として決まったルールに則って回すマクロワークフローの組合わせの仕組みで、働いている人たちがしたい仕事の流れそのものを表現するものにするのです。

前回、ミクロワークフローとマクロワークフローの組み合わせがこれからの業務システムに必要になると書いた。これは実際にはミクロワークフローはCMS(Contents Management System)でマクロワークフローはBPMS(Business Process Manegement Suite) を使います。ではこの仕組みはどんないいことがあるのでしょうか。前回も触れているのでもう少し具体的な話をしたいと思います。

ずばり、業務の品質と時間（生産性）を向上させます。これらを少し詳しくみていきます。業務の品質とは一体どういうことでしょうか。

業務の品質というのは「意思決定のレベル」だと思っています。何も調査もせずに、あるいは誰にも相談しないで決めたものと、よく吟味して、いろいろな立場の人から意見をもらって決めた事はその品質は違ってきます。

従って、そうした参照情報へのアクセスやアドバスしてくれるメンバーが揃っている“場”が必要になるのです。こうした“場”はCMSで提供されます。ただし必ずしもCMSでなければいけないということではありません。要は、情報共有空間で集合知を活用して、そこで何かを決めて承認できるということであれば、SNSのようなものでもかまわいませんし、他のWebアプリケーションでもかまいません。

こうすると副次的効果としても、たとえば技術の継承みたいなことも可能になってきます。ノウハウを持った人がその場に参画し、若い人がやっている仕事をみて、必要に応じてアドバイスするという流れにすれば、そのコメントそのものがアーカイブされ、貴重な教育資料になるのです。またコンプライアンス上でも相互監視の仕事になりますから、不正なアクションはおこせなくなります。

一方、時間という面では、意思決定がスピーディになるということです。なぜかというと、情報共有の場では関連部署のメンバーやアドバイザー、承認者も最初からそこに参加することで、意思決定していく過程を見ているので、例えば承認伺いが来たときには素早く判断がつくというわけです。

これまでだと、紙で決済伺いが来て、それを見た上長はいきさつがわからないのでその経緯を説明しろとなる。言われた人間も自分が書いたものでないからまた部下にヒアリングするなんてことがおきていやしないだろうか。

また、BPMSではプロセスの進行をモニタリングしていますから、どこかのアクティビティで停滞が起きたりするとアラートを発するので、業務の進行を促してくれます。これも業務スピードを向上させてくれる仕掛けなのです。

おわかりのように仕事をオープンにしてそこにみんなを参加させて仕事をするということは、生産性と業務品質を向上させるのです。

よくせっかくシステムを作ったのに利用してくれないとか、いいツールを与えたのに以前と同じやりかたでしかやらないとかいう声を聞きます。それはいつも情報リテラシーが低いとか意識が変わらなくて困るという話になります。

先日ある記事を読んだときもそんなことが書いてあったので紹介します。

6月11日に米国ボストンで開催された「Enterprise 2.0」イベントで、ブログやwiki、RSSフィードといったユーザー生成コンテンツツールを企業で利用する際には、中間管理職の存在が1つの大きな壁になっていると、パネリストらが論じ合った。 これは、懸念すべき事態といえる。一般に企業は、ビジネスプロセスを円滑に進める役割を中間管理職に求めている。彼らがブログやwikiを使用した情報発信に参加しなければ、仕事が滞ってしまうのではないだろうか。中間管理職が本当にそうしたツールを受け入れなかった場合、ワークグループのコラボレーションが散発的になったり、効果が薄れたりすると思われる。

これは米国の話だから、日本ではもっと大きな壁がありそうです。

ではどうしたらよいのだろうか。上の記事でもそうだが、ブログやWikiなどを対象としているが、こうした使い方では個人差も出るし、だいいちそれを使わなくても仕事ができることのように思えます。

今だって、電子メールより電話の方が早いし、ちゃんと伝わると思っている人がいるわけで、単なるコミュニケーション手段が今様なものを使えというのではインセンティブたり得ないのです。いくら嘆いても普及するのは難しい。

この解決策は、“それを使わないと仕事にならない”状況を作り出すことではないでしょうか。

この米国の例でもワークグループのコラボレーションと言っていますが、業務システムをオペレーションするのに使っていない、あるいは業務システムの機能に組み入れられていないのです。ですから、使わなくても支障がないやとなって使わない人も出てくるわけです。

ですから今提示しているようにフロントエンドにCMSをもってきて、その場のコラボレーションにより、ワークフローを回していくことにすれば、自ずとそのツールを使わないと業務の進行を妨げることになるので必然的に使わざるを得なくなります。

システムというのは自然と使わざるを得ないものになってこそ生きたものになると思っています。このような自律的な姿をどう実現させるのかが重要なポイントになるのです。
　

業務プロセスが化学プロセスと似ているという話をしたが、もう少し範囲を広げて考えてみることにします。前の話では連続プロセスのイメージがつよかったと思いますが、製造工場には上流の原料受け入れから、製造、保管、最下流の出荷まで各種の製造プロセスがあって、各工程のプロセスは連続プロセス、バッチプロセス、ディスクリートプロセスと混在した形でいりこんでいます。

連続プロセスは化学プロセスに多く、液やガスが一旦投入されると連続的に流れて製品が出てくるといったものです。バッチプロセスというのは、化学でいうと反応釜のようなものに原料を仕込んでそこで生成された製品をそこから抜き出して、また次の原料を仕込むようなものです。ディスクリートプロセスというのは半連続的に流れていくが機械的に搬送しながら流すようなものです。自動車の生産ラインもこれにあたります。

ですからわれわれ化学屋はこの自動車の組み立て型のプロセスがなかなかなじめないところがあります。プロセスの違いもそうですが、化学プロセスは基本的には組み立て型と違って展開型なのでそこもあります。化学ではレシピ（配合表）といいますが、組み立て系ではBOM（部品表）です。

もうひとつ、ベルトコンベアーのような流れ作業型のラインに対して、キャノンがやったようなセル生産方式というのもある。システム開発でいうとウオーターホールとアジャイルみたいなものです。

なぜこんなことを書いているかというと、生産プロセスのほうが業務プロセスよりもっといろいろなかたちがあったり、高度化されているから、そういうところを研究、学習し、活用することが必要であると思うからです。

さらに、そのシステム自体もはるかにすごいことをやっていて、例えば制御ステーションの考えなんかブレードサーバーと同じだし、冗長性なんかかなり高度な仕組みになっているし、EBSなんてプラント制御では最初からバス接続の方式である。また、データ活用なんかでも、データウエアハウスとかBIなんて言っているけど、プラント系ではリアルタイムデータを解析していたり、高度なシミュレーションをやったり、最適化制御もやられたりとすごい差があるように思える。だから、こうしたことをうまく転用することも考えた方がいいと思う。

でなぜ人とITなのかというと、生産プロセスはそれをきちんとコントロールしていることと、そのプロセス全体をオペレーションしている人がいるということなのです。ここのところが業務システムの弱いところではないかと思っているのです。