« 2011年3月 | メイン | 2011年9月 »

2011年8月 アーカイブ

2011年8月19日

カジュアルBPMのすすめ 

BPMに対する考え方をちょっと変えてみよう

ぼくは、BPM(Business Process Management)に携わっている人間としては、期間からいうと日本でもかなり長い方だと思う。もうかれこれ10年近くになる。この間、何らかの関わりを持ちながらずっと来ている。しかしながら、この10年間でちゃんと理解され浸透してきたのかというと残念ながらそうはうまくいっていない。

ということは、受け入れられない何らかの理由があるわけで、その理由には、もともと筋のよくないものなのか、筋はいいのだがプロモーションができていないのか、それともタイミングが悪いのかといったことが考えられる。おそらく筋のよくないものではないというのは皆さん同意してくれると思うので、受け入れられない障壁は何なのだろうか。

そのひとつに、BPMをやるのだ、BPMに投資をするのだといって構えてしまうことにあるように思う。ひところのERP導入と同類のように身構える。なぜそうなのかというと、大きな投資をするのだから失敗は許さないという雰囲気があるのと、投資対効果が出しずらいというのが横たわっているような気がする。だから、もっと気軽にやれたらと思うのである。

そんな思いから、これから何回かにわたって「カジュアルBPM」というテーマで書いていこうと思う。フォーマルBPMというのがあるかどうか知らないが、気軽に、そして気楽に普段着を着る感じでできないかということである。

今このことをめざす時にいちばん手っ取り早い考え方は、いかに安くやるかである。そして、変な前提を取り払うことだと思う。その前提というのは、BPMはIT化すること、もっと入れ込んで自動化することだと思っていることである。この両者は関係があって、従来のシステム開発はコードを書くことだから、多くの人数をかけて、何回も仕様変更、手戻りをして作ることになり、その工数がすぐさま開発費に跳ね返ることで非常に高価なシステムができあがるというわけだ。

これは、ITを使ってシステム化することが目的化しているからで、そこの目的を自分たちのビジネスとか業務を円滑に進められる仕組みであればどんな形でもいいとしたらだいぶ様相が違ってくるのではないでしょうか。だれもBPMはITを使わなくてはいけないなんて決めたわけではないでしょう。

ですから、カジュアルBPMを考える上で重要なことは、別にITを使わなければいけないということではなく、自分の会社あるいは組織に見合った仕組みと仕掛けを構築すればいい。だから、それがExcelかもしれないし、ホワイトボードかもしれないのだ。そんなことをしばらく考えてみようと思います。

システム化とIT化は違う

前回、別にITを使わなくてもBPMはできるというお話をしましたが、そのあたりをもう少し考えてみましょう。情報システムに関係している人たちにある大いなる勘違いがこれである。システム化するというとIT化、すなわちソウフトウエアを使うとかプログラミングすることだと思っている節がある。少なくとも、すぐにそういう発想をする人が多いと思う。情報システムという言葉もよくない。

システム化の要求というのは、業務あるいは業務プロセスがシステマティックになっていないことからくる非効率性があるので、それをシステマティックな形態に変えようということである。このシステマティックというのはどういうことなのであろうか。

日本語だと、組織的なとか系統だった、体系的なといった意味合いの言葉になるように、いちばん分かりやすいのが組織です。組織を決め、そこに人を割り当てて役割を与えることです。これだけでも立派なシステム化になるのです。それから仕事をどういう順番でやるのかとか、どういう規則に則ってやるのかとか、誰が決めるのかとか言ったことを整えていくわけです。

そして、そうした活動を円滑に行えるようにいろいろなツールを使うようになります。原初は言葉だけでやりとりして、人間の頭の中の記憶として残すなんてことだったかもしれません。それが紙に書いたり、保管庫にしまっておくとか、電話を使ったりするようになったわけです。これもシステム化です。ですから、システムを高度化する中でITが使われているに過ぎないと言ったら言い過ぎだろうか。

以前からよく言っていることですが、業務システム開発というのもおかしな言い方で、決して開発するものではなく、すでにあるシステムの一部あるいは全部をITに置き換え高度化しているだけなのである。これは当然といえば当然で、ビジネスを行っているということは、レベルはどうであれ、何らかのシステムの上で動いているだけなのである。

そう考えてくると、業務プロセス設計というのもおかしく思えてくる。業務プロセスは設計するのではなく、記述すると言った方が正しいのかもしれない。つまり、設計するのは業務プロセス構造の方であって、業務プロセスではないのである。要は、今行われている業務プロセスを表現するのに適したプロセス構造を設計して、その構造の中に自分たちの持つ業務プロセスを記述していくという観点が正しいような気がしてきた。

ただ、そうはいってもITがそうしたシステムを変えていくこともあるような気もする。すばらしいITが登場することで、システムがそれにつられて変えていかざるをえなくなるといったことでありそうである。例えば、コンビニのPOSみたいに。こうした技術があったからそのような店舗形態ができたとも言えるが、この例でも、まだそこまで行っていなくて、むしろ前述したようなシステムの高度化の段階なのだと思う。

以前セブンイレブンの人が話していたが、彼らはITよりビジネスモデルが先行していて、自分たちがこんなことをしたいと思っていてもITがついて来ていないのでできなかったことがあって、その後その考えを具現化できるITが登場してくるとすぐに適用するとのことである。競争に勝てるのはこうしたビジネスモデルから出てくる要求のレベルの差なのかもしれない。

つまり、ITがついてこれなかったら、手でやるしかないのであって、それはモデル上は同じだが、パフォーマンスがでないといったところに問題が顕在するわけで、それがITで解消されると格段に効率化できるとかいった結果をもたらす。そこでの費用対効果が正当化できれば実行に移すだけなのである。
  
ITがToBe化するわけではない 
 
前回、前々回とシステム化するとなるとすぐにITを持ちだすことをするなという話をした。今回もしつこいようだが似たような話になる。なぜここまでそうした議論をするのかというと、ここが非常に重要なポイントだからである。

ITから発想すると経済的かつ技術的な壁がすぐに立ちはだかって気楽に、すなわちカジュアルな感じでシステム化ができないのである。少なくとも従来のシステム化の考え方、あるいはシステム化をする人たちの頭では、軽い乗りでやろうとするととんでもないことだと拒絶されること必定である。

これから、主張していくことは昔かたぎのIT屋さんからみると、だから素人は無茶なことを言うから困るなんてことだろう。しかし、いつまでたってもビジネス屋さんから満足されないのはどうしてなのだろうか。やはり、小手先だけの改良では無理で、発想の大いなる転換が必要なのだと思う。

だから、ビジネス視点でプロセス先行、そしてITからまずは離れて考えるということをしつこく言っているのだ。IT屋さんはビジネス要求があるとそれをITでどうやって解決しようか、ITだとこんなことができるという発想をする。それをやめなさいということです。そういうものの見方というのがカジュアルBPMの譲れない立ち位置なのである。もちろん普通のBPMも同じではあるが。

前回、まずは業務プロセス設計というより業務プロセスの記述からということを言いました。つまり、ある業務プロセス構造に従ってAsIsを記述するということです。こういうとAsIsから書くとそれに引っ張られてToBeが書けないという人もいますが、AsIsがちゃんと書けなければToBe化は難しいと思います。

ただ、ここでITを持ちこむと変なToBe化になります。例えば、使おうとしているソフトウエアにそうした機能がないと違うToBeになったり、ベストプラクティスと称して、その会社には不釣り合いのToBeになったりします。

ToBeに持っていくまではITは関係ありません。きちんと構造化されたプロセスとしてAsIsが記述されれば、その事実を分析すれば、あるいはもっと前の段階、つまり書いているうちに、ToBeの姿が見えてくるものです。

ここで、大事なことは「構造化されたプロセス」ということで、ただやみくもに仕事の手順を書いているだけだと見えてこないかもしれません。こうして、どんな業務プロセスにしたらいいのかが表現されたら、そこでこれを実現する手段を考えるということになります。
  
プロセスはどこにでもある

これまでしつこいようにシステム化というのは必ずしもIT化を意味するものではないと言ってきたが、別の角度からカジュアルということを考えてみる。それはTPOからみたとき、決められた時間とか、定まった場所とか、あらたまったケースといったところだけにシステムを適用するわけではないということである。いついかなるときでも、どんなところでも、どんな場合でも、プロセスがあり、それへの対応がある。

ちょっと前に、ディズニーランドの地震時の対応の話を書いたが、あの場合にもプロセスがあって、その
プロセスを円滑にオペレーションしたからこそ、みなから称賛されたわけである。もっと言えば、この震災でそれこそ想定外の事象がいたるところで起こってきて、それへの対処で称賛されたり、その一方で非難されたりする。これは、全部プロセスオペレーションの問題なのである。

原発の事故処理にしても、被災地支援にしても、復興事業にしてもみなプロセスが形成されているのである。それは、はいこれは○○プロセスですとは、名づけられないが、どこからか依頼とか要求があって、それに答えることをしているわけである。それを、早く効率的に、より適正に行うことが求められているのである。

そして、もう少し思慮深く行おうとすると、ビジネスモデル、ここでは事業モデルと呼んだ方がいいが、その事業モデルをちゃんと確立しておくことが必要だ。例えば、被災地への支援活動でも、単に支援をするというのではなく、被災地支援の事業モデルを作った方がいい。どこのだれを支援するのか、支援の形をどうするのか、物資を届けることなのか、人的サービスを提供することなのか、そして、どんなリソースを使ってそれらを提供するのかをよく定義しておくべきなのだ。

そして、それをどういうサプライチェーンで被災地まで届けるのか、そしてどんな対価を得るのかである。この最後の対価うんぬんは、ビジネスではないから無視するとなりそうだが、お金ではないところで対価を得るべきだと思う。例えば、感謝の言葉でも何でもいいからサービスの提供とその対価は見ておいた方がいい。そのほうが、与えるサービスの効果を意識するからである。

この事業モデルから、それぞれで必要なプロセスが生じてくる。例えば、支援物資の調達プロセス、輸送プロセス、ボランティア要員募集プロセスといったプロセスを設計してオペレーションするのである。それも、素早く的確に設計できなければいけない。

おわかりのように、こうしたプロセスを開発している暇はありますか?要件定義して、コードを書いてシステム化をしますか?それに、ITシステムがないからこうした活動ができないのでしょうか。そうですよね、パソコンを使おうが使うまいが、システムがあろうとなかろうと、携帯でやろうが、体育館のホワイトボードに書こうが、支援活動は行われます。

こうしたものにも対応できるのがカジュアルBPMであると考えてみらいかがでしょうか。被災地支援は特別だとおっしゃるかたがいるかもしれませんが、普段やられている忘年会やいろいろなイベントも同じですので、ちょっとその気になって考えてみてはいかがですか。
  
被災地支援ができないSIer

前回、被災地支援活動を例にいついかなる時も役に立つようなプロセスを提供できるのもカジュアルBPMの務めであるというようなことを書いた。そういう思いの背景には、SIerと呼ばれる業種がこの震災の時にどういう支援ができたのだろうかと考えたことも影響している。普段、会社の業務システムを手掛けているところがどんな支援の手をさしのべられるのだろうかということである。

ハードやソフトウエアのベンダーとか、データセンターなどは何となく保守サポートの特別サービス、データセンターでの各種無償サービスの提供、復興事業に関する無償ソフトウェア提供といった支援が浮かんでくるがSIerにはイメージがわかない。せいぜい、被災されたお客さんのシステムの復旧やサービスの維持くらいだ。

だから、役立つ存在ではないという短絡的な見方はしないが、何となくさびしく感じるのも確かだ。みんなが支援や復興に向けていろいろとやっているのに取り残されているようにも思える。そこのところがある意味象徴的で、ビジネスの今を作れないのだ。

前回にも強調したが、要件を定義しておもむろに作り出すようでは、この世の中の早い流れにはついて行けない。しつこいようだが、そこのところを根本的に変えていくやり方を提示できないとますますユーザから見放されてしまうと思うのだが、多くのユーザも含めて鈍いと思うのはぼくだけなのだろうか。

新規の場合でも、変更の場合でもすぐに対応しなくてはいけなくなる局面では、いきなり動くものを持ってきてサクサク作ってしまうぐらいの勢いをもつことをしないと変革要求には答えられないだろう。そうした要求はずっとあったように思うが、今までのようにみんなが安定的に食えた時代で、しかも作り手側も使い手側も持ちつ持たれつの関係の中ではなかなか顕在化してこなかったのではないだろうか。

このSIerの組織は分類から行くと、「鈍重型組織」まではいかないが「慎重型組織」と言えるのではないだろうか。つまり、淡泊で臆病な組織である。相互理解という面では容易なのだが、そのぶん試行したり実験したりということが抑制されている。

ちょっと、組織論に話がそれてしまったが、ここで言っているカジュアルBPMというのは、この試行したり実験したりするハードルを下げてあげることにもつながるのだ。すなわち、現代における優れた形式として「試行型組織」が求められていることに対するひとつの答えになりうるものであると思うのである。

コピー機を売るように売りたい

何を売るかって、もちろんカジュアルBPMである。またずいぶんと違うものを一緒くたにして分けがわからないとお叱りを受けそうだがまじめです。これまでの業務システムの売り方はどうだったでしょうか。ソフトウエアプロダクトとかパッケージあるいはデバイスといったものだと似ているような気もしますが、業務システムってまるで違うように見えます。

では、コピー機を売るということはどんなことかというと、どこかに新しい事務所を開設したので持ってきてくれとか、今はコピーだけの単機能ではなくて、FAXプリンター機能もある複合機ができたからそれに変えたいといった要求があると、ハイ分かりましたといってすぐに届けて、すぐに使ってもらうことを意味している。

だいぶ飛躍して言っているが、このくらいの発想の転換が必要ではないだろうか。少なくとも、そうしたものにするにはどうしたらいいのかぐらいの思考はしたらいいと思う。だいいち、今までと同じことをユーザは望んでいないのだから、一回ゼロベースで考えなおしてみるということだ。

この発想は、これまでの議論からいうとけっして突飛なことではないと思うので、このブログの記事を読んでくださっているひとは理解が早いのではと期待している。基本的なスタンスとして、ITはあくまで道具であると言っているわけだから、いくら業務システムと言いながらもITの集積だから、コピー機と同じオフィスでの道具なのである。

前に言ったような新しい事務所を開設したようなケースだと、開設と同時に購買のシステムをダウンロードして、あるいはUSBを差し込むとすぐに購買システムが立ちあがって、あとは必要なものを設定するとすぐに動くという感じですかねえ。

そう言うと、みなさんそれはクラウドでしょというが、それは提供形態を言っているだけで、提供されるものを言っていない。それはパッケージでしょうという人もいます。では世の中にあるパッケージがそうした買われ方をしていますか。

日常の組織としての業務やグループでの仕事といったものが、すぐに動かせるというのはあまり見たことがありません。すぐに、その組織固有のあるいは例外的な機能があるから、ケースバイケースで対応することばかりだからという理由を付けてそんなことはできませんという答えが返ってくる。

そこのところを突き破らないとどうしようもないと思うのだが、まだま要件を聞いてそれをコードに起こしてという発想しかないのではないでしょうか。そして、作るまでで疲れてしまい、それをどう使うかまでいかないのである。ですから、そこは出来合いにしておいて、どう使うかに集中するのである。コピー機ってそうですよね。

スタイル起点

まだ、概念的な話が続き恐縮ですが、思想の転換、パラダイムシフトといった変革を促すには、こうしたコンセプチャルな理解が必要だと思うからしつこく議論しているわけです。何回も似たような話をしているので、食傷気味かもしれませんがもう少しお付き合いを。

人々の普段の生活にITはどう入りこんでいるのでしょうか。少なくともITを使っているという感覚はあまりないのではないでしょうか。ITが埋め込まれたデバイスを使ってるという意識はあると思いますが、生活に必要なシステムをコードを書いてもらって作ってもらうということはないでしょう。家計簿システムを開発するなんてしないわけで、さらに別にITではなくてもよくて、主婦の友社の家計簿ノートを使えばいいじゃんとなる。

つまり、人々はITをどう見てるかというと、まずは自分の生活スタイルがあって、その生活をより楽しく、より有意義なもの、より楽にするといった要求に答えられるものを相応のコストで手に入れたくて、そこにITが埋め込まれてコスパが優れていたら使いますよという感じでしょうか。

ここで重要なことは、「自分の生活スタイル」ということです。山の中の静かなところに一軒家を買ったので、いままで都会のマンション暮らしでは必要なかった車を買った。ただ、その車は買い物だけに使えばいいので軽自動車でよかった。これが、日々の暮らしにおけるスタイルからの発想である。

さて、このことを企業や他の仕事組織について考えてみましょう。「自分の仕事スタイル」「組織の活動スタイル」「会社の経営スタイル」というのが浮かんできますよね。こうしたスタイルを考えているのでしょうか。少なくともビジネス側の人たちは大なり小なり、あるいは意識しているかいないかにかかわらず持っていると思います。

ところが、業務システム開発というとどうもこんなことは無視しているというか、関心がないように思われます。極論すると、電子計算機にどういう計算をさせるかだけを考えているように見えます。インプットとしてどんなデータを入れて、そこで情報処理をしてもらいその結果をアウトプットとしてどんな一覧表を出力するのかを設計するのです。

生活スタイルのなかで使われるITを活用したデバイスにはこんな役目のものは少ないはずです。ここが大きな問題だと思うのです。さきほど、軽自動車の話をしましたが、近くのスーパーに買い物に行くというのが生活スタイル中の活動としてあります。これは、プロセスになります。つまり、生活物資を補給しなくてはいけないという要求があって、それに答えるべく近所のスーパーで必要なものを購入して家に持ち帰って格納するというプロセスです。

そのために、様々なITを使います。車も最近ではITのかたまりみたいなものですし、売り場で携帯電話を使って確認するとか、場合によっては、一部の商品は少々高くてもいいからネット通販で買ってしまおうとか、スタイルに合わせて使い方を工夫しているわけです。

ということで企業分野に目を転じると、こうしたスタイル起点でそれに合った仕事や業務のデバイスを使うという切り込み方で業務システムを考えているでしょうか。今一度、スタイルを起点として、そのなかにITとしてどんな役割、位置を占めるべきかをじっくりと考えてみたいものです。

あるセミナーにて

さて、これまでお話していたことをある程度実践した例をご紹介しましょう。ついちょっと前に、バリューチェーンプロセス協議会(VCPC)主催のセミナーがあって、そこで今野製作所の今野社長が「中小企業にプロセス参照モデル」は使えたのか?」というタイトルの講演を行いました。渡辺和宣さんが中心となって、SCORとその分解モデルであるESCORTを使って、昨年夏から、業務プロセス分析を行い、プロセスの再設計とともに実装までやってみようというプロジェクトの成果発表でした。

実はぼくもこのプロジェクトに参加していて、この実装のところを2月から始めました。ところが、今野製作所は福島の相馬郡に工場があったものですから、震災の影響をもろかぶってしまい、長期のブランクを余儀なくされました。幸い工場が高台にあったもので大事には至らなかったので、連休明けにはプロジェクトも再開しました。

ですから、ほんの短い期間で設計から実装ということを行ったわけです。対象プロセスは、受注設計生産品の顧客要求受付のところから、与信、販売チャネル確立、見積提示、見積のための提案仕様作成、原価算出、そして見積書の提出といった一連のプロセスです。

最初はどうやって実装するのかは頭の痛い問題でした。というのも、今野製作所は30人の会社ですから、現実問題としてお金をかけられないという前提があります。そこで、知恵を絞って考えた結果、既存のソフトウエアを有効に使うことにしました。そこで利用したのは、既に使っているサイボウズ社の「ガルーン」というグループウエアと「デヂエ」というデータベースソフトです。

どうやったかは、このブログでご紹介していきますのでここでは詳しく言いませんが、要するに大事なことは、業務プロセスを設計して、それを動かすということは、別に高価なあるいは高機能のツールを買わなくてもいいということです。

ところで、このセミナーで非常に興味深いことがありました。もうひとつの講演でNECの方が「全社業務プロセス/IT改革 事例紹介」というプレゼンを行いました。NEC全体の業務プロセスの標準化を中心に改革を行った事例です。この二つの講演の対照がすごく印象的でした。つまり、かたや30人でほとんどお金をかけないケース、かたや14万人で数百億円の投資で実施したケースという対比です。

ところが、こうしたとてつもなく大きな差はあるにしても、やっていることはそう変わらないというのが偽らざる感想でした。まず、どちらもプロセスエンジンを使っていない点です。NECのケースでは、基本的にはARISとSAPから成っています。すなわち、ARISでプロセスを記述して、それに基づき、SAPに実装して、その結果を抽出してARISにフィードバックするという仕組みです。

でこれを、今野製作所に当てはめると、SAPの代わりがデヂエでARISの代わりがExcelかパワーポイントになります。こんなことを言うとそんなばかなとか、暴論とののしられそうですが、結局超簡単に言うと、プロセスをどう書いて、そのプロセスを動かす単位要素としてあるデータの登録画面をどう使っていくかなのである。

そこにプロセスエンジンがないから、その回し方の工夫をどうやっているのかになるわけです。ぼくの個人的な感想だとその工夫は今野製作所の方が優っていると自負しています。すいませんNECさん。ここらあたりはソフトウエアの機能だとかIT技術の高さだとかいったものではなく、コンセプトとか思想の問題になる。だからこそ、このブログでも口を酸っぱくして言っているのである。
  
セミナーにて(続き)

前回、中小企業と大企業の比較を書きましたが、別に大企業を批判しているわけではないので誤解しないでください。むしろ、プロセス志向で業務を整理して、それからSAPを導入し、しかも戦略―設計―実装―運用のサイクルを回すための基盤を整備したというのは評価できるのではないでしょうか。

実は、今もそうだかわかりませんが、以前はSAPを導入するとなると往々にしてシステムの枠組みにプロセスを合わせてしまうというやり方になっていました。それを、プロセスに必要なシステムを組み合わせるという方向に変えていこうという動きがあったはずなので、そうしたアプローチをしているわけで考え方はいいと思います。

前回の少し補足をしておきますと、重要なポイントというのは、業務システムをゼロから作るわけではないということです。会社の規模が大きくても小さくても、古くても新しくても、どんな会社も必ず業務プロセス、業務システム(ITを使うという意味ではありません)があります。そうした業務の流れ、仕事のやり方をもっと効率的にとか早くしたいとかいう要求があって、それをどうやって実現するかを考えることが最優先なのである。

そのために、業務プロセスを記述することを行うのである。それを、ARISのような高級ツールを使おうが、VisioやExcelで書こうが、ちゃんと管理できればいいいと思います。(ARISはそういう意味では管理機能が大変優れているから、それとコストが見合うかを評価すればいいのです)

要は、業務オペレーションがきちんとできるようなプロセス構造と機能が定義できるかにかかっていて、簡単に言えば、決めるべきこと(意思決定)は何か、その順番はどうするのかということを定義するのが構造で、その構造に従って、どうやって決めて、そのあと次の決めごとに取りかかって必要な意思決定を全部行うのがオペレーションなのである。

ですから、具体的には意思決定の結果はデータ登録で、次に進めるのが進捗管理となります。ただし、データの登録と言いましたが、それが重要なのではなく、そこまでに至る過程、つまりデータをどうやって確定したかが最も大事なことなので、それがうまくできる仕掛けを用意する必要があるのです。場合によっては人間がやってもかまわないわけです。

また、プロセスの進捗管理もそれを進めるのを何も自動的にやる必要もなく、人間が手で進めてもいいのです。紹介したセミナーの事例でもここは人間が進めています。そういう意味でITで自動化するなんていうのは最後に考えればいい問題なのです。

システム屋さんの根本的な誤解は、業務プロセス設計して(ちゃんとプロセスが書けているケースは少ないですが)すぐにそれをITに実装するというアプローチをしてしまうことです。そしてIT化するための要件定義をするわけです。それではIT化することが目的となります。これが間違っていると言いたいのです。
  
プロセス先行、実装独立

これまで、カジュアルBPMの姿を概念的なレベルで見てきましたが、イメージとしては提示したので、これからは実際にどういうものを作ればいいのかという議論に入ります。抽象的なことばかりだと机上の空論と非難させるので具体的なやりかた、実際に動くものを検証していきたいと思います。

それを考える上で重要なアプローチはプロセス先行ということです。会社は経営理念や経営方針があって、それに対する戦略があり、それを実行するためのビジネスモデルとそれに従って行動する「スタイル」があります。そして、このあたりからプロセスが登場してきます。この段階ではITは意識しませんし、どんな業務システムにするとかといったことも出てきません。あくまで、ビジネスモデルを実現するためのプロセスはどうしたらいいのかから入ります。これがプロセス先行ということです。

このように実装独立で見ていきますから、どんなITを使うかは出てこないということになります。別な言い方をすると、実装方法はどうであれ、プロセスを記述し、機能を定義するわけですから、どんなやり方でもそのプロセスは実行できなくてはいけないことを意味します。ここが、カジュアルたる所以のところです。

タキシードを着ないと晩さん会には行けないというのではなく、公園に遊びに行くならTシャツでもいいし、セーターでもあり合わせのものでいいのです。ちょっと飛躍したかもしれませんが、要は自分の手持ちに応じて臨機応変に実装すればいいということである。

すいません、またまた抽象的な言い方になってしまいましたね。ここでプロセス先行と言っている意味をもう少し考えてみましょう。実際のビジネスシーンで見ていくと、業務の流れとか、仕事の段取りや進め方を最初に決めていきましょうということです。その方が、何と言ってもビジネスの人がわかりやすいということです。さあ、ER図を書きましょうと言っても無理なわけです。

それと、プロセスの意味をもう少し広めに考えていきます。よく、業務フローとかワークフローと言いますが、これだと単に仕事の手順になってしまいますので、フローだけではなく、そこにあるタスクを実行するためのもろもろのアクションなども含めて考えることにします。ですから、場合によってはフローだけではなくストックも含めていきます。

そう考えると、普段皆さんがやっている業務あるいは仕事そのものを指しています。ですから、それはいったい何をしているのかを突き詰めていくことになります。簡単に言うと、前回にも申し上げましたが、意思決定をしてその結果であるデータを登録することと、そうした意思決定を順番に流していくことです。

ここで少しITのことにふれておくと、データを登録するということは、現在ではほとんどの、いやあらゆる会社でITを使ってやっていると思います。何億円というメインフレームのレガシーシステムから、家にあるPCかもしれません。DBもOracleやDB2からExcelまで種々雑多なものがあります。ここだけはこれでいいと思いますし、ITを使います。

ただ、これはITを計算機として使っているだけなので、そこのところへいくまでにITはどうなっているのでしょうか。もうおわかりだと思いますが、カジュアルBPMにおけるポイントとなる機能はデータの登録のところではなく、データを登録する前の動作のところと、単なるワークフローではないプロセス進行のところになります。
  
データ登録からデータ確定

前回の最後に言ったことは業務オペレーションをどうやるのかということに他ならない。ただ、ここで注意しなくていけないのは、業務を遂行するプロセスを開発プロジェクトと称してスクラッチで作ろうなんて思わないことだ。業務を遂行するということは当たり前だが、大昔からずっとやっていることなのだから、そのやり方を便利なツールがあったらそれを使ってみようという態度でいいということだ。

つまり、そこを考えるとき大いなる間違いが、何でもかんでもITを使おうとするから、ITに向かってデータを登録する仕組みをすぐに浮かべることである。そうしたアプローチだとITに入力して処理をしてもらって閲覧なり、レポート出力してもらうことが仕事なのだと勘違いしてしまうのである。

もちろん、それも大切な仕事であることは否定しませんが、これまでの業務システムの考え方は、データ登録に重きを置きすぎています。ですから、ここのカジュアルBPM精神のポイントは、「データ登録からデータ確定へ」です。ここの発想転換の意味を理解することが重要です。

データ確定(意思決定)は、定型的でないことが多いためにITのスコープ外になっていました。そうですよね、ITは決められたことしかできませんから、行ったり来たりするとか、あいまいさが含まれたり、例外であったりすることを拾えませんでした。ところが実際に職場における仕事はこんな非定型の処理がわんさとあります。

そして、ここのところが実は良くも悪くも非常にその会社、組織、メンバーの特徴が現れるところでもあるわけです。会社の方針を忠実に守っているのかとか、事業計画通りにこなしているのかとか、リスクをちゃんと認識してチャレンジしているのかとか、過去の失敗を繰り返していないだろうかといったことがここの局面に現れてくるのです。

いくら立派な戦略を立てても、すばらしい中期計画を作ったところで、ここで実行されなくては全く意味がないのである。いいですか、戦略や事業方針、計画を実行するのはデータを登録して計算、集計するERPではありませんよ。それらは結果をまとめるだけなんですよ。戦略、方針、計画を表現したデータを作ることがどれだけ重要であるかおわかりなったでしょうか。

非常に高いお金を払って買ったシステムが、データ登録、集計、レポート出力システムであったわけです。そして、そこへ入れるデータを作るのは今までと大して変わらず、電話やFAX、メールでやり取りして、EXCELシートに書きこんで計算したり、書き変えたりした結果を入力専門の人がそれを見ながら打ち込んでいるのではないでしょうか。まあ、最近はSOAと称して、ここをデータ連携ツールを入れて自動的に入力しているでしょうが。

ということで、今回のポイントは繰り返しますが、データを登録することが重要ではなく、そのデータをどうやって作って、確定させるかがより大切なアクティビティであることを認識することです。なぜなら、ビジネス要求を具現化するところだからです。

カジュアルというのは、いいかげんにやればいいというわけではもちろんなくて、ベースのところをきちんとしておいて、そこはぶれないで表面を自在に変えるということでもあるので、ベースは今言ったようにデータ確定のところの考え方をしっかりもつということになります。
  
どうやってデータを確定するのか

前回、しつこいほど「データ登録からデータ確定」ということを言いましたが、それではどうやってそれをやるのでしょうか。それにはまず、今はどうやっているのかを見ていきましょう。ここは会社の規模や業種業態はあまり関係なく、大企業であれ、中小企業であれ、また製造業であれ、サービス業であれ基本的には同じではないかと考えています。

今はまだ、データ確定がけっこうインフォーマルな世界で処理されているような気がします。つまり、責任のある人があずかり知らぬところでとか、人の頭の中でとか、あうんの呼吸でとか、そんな動きの中でデータが決まってくる、あるいは判断がなされているのではないでしょうか。ですから、このことは記録にも残らないことになります。何となく暗黙のうちに物事が決まってしまうという日本的な空気かもしれません。

こうしたことは、あまりいい結果をもたらさないと思うのですがいかがでしょうか。雇用の流動性のない終身雇用で右肩上がりの企業成績の時はそれでもよかったでしょうが、少なくともこれからの時代では、こんなやり方で仕事していたら困ってしまいます。確かに道具はPCが机の上にあったり、メールが行き交ったり、Excelを使い倒しているかもしれませんが、本質的には変わりません。こうしたコミュニケーションや個人の生産性の向上に寄与するツールは登場していますが、組織だった業務オペレーションで威力を発揮しているでしょうか。

これからの時代、内部統制を持ちだすまでもなく、表に出た形でデータ確定をする必要があります。すなわち、誰がどうやってデータを確定し、承認したかが問われてきます。そしてこのどうやってという部分が従来と違うようにしなくてはいけないのです。隠れて決めてそれを登録したときに初めて表に出るようでは、そこの業務を制御して管理しているとは言えません。

ここで大事なのは、データ確定のプロセスを経ること、つまりデータを起案あるいは申請し、それを確認や調整といったことで判断や確定をし、それを制約などでチェックして承認するという手順を実行することがあります。そして、それぞれの段階で誰がやるのか、起案する人、確認あるいは調整する人、そして責任をもって承認する人をちゃんと決めて参加させることです。

これは、単にアサインしておけばいいというわけではなく、コミュニケーションをしながら先に言った手順を遂行することが重要です。さらに、そのコミュニケーションの内容を記録に残すことでインフォーマルな世界から、オープンでフォーマルなものへと変わっていくのです。

そしてもう一つは、起案・判断・確定・承認といった行為を行うときに何を参考にして、あるいはどういった基準に基づいてやっているかがあります。それらはほとんどが「情報」という形で見えてきます。ですから、こうした参照情報をどこから持ってきてどのように見せるかが大切です。

結局、コラボレイティブな場で関係者がみな参加して必要な情報を参照しながら意思決定する(データ確定する)というのがあるべき姿なのである。
  
カジュアルBPM実装のための要件

前回、関係者がみな参加して必要な情報を参照しながら意思決定する(データ確定する)コラボレイティブな場が必要だと説きました。また、その前にプロセス先行で考えること、そしてそれをオペレーションする重要性も強調しました。そうしたことを鑑みて、ここで標榜しているカジュアルBPMを実際に装備し実行するにはどんな要件が要るのかを考えてみましょう。

間違ってはいけないのは、BPMSの機能を持ってきて、やれモデラーだ、ワークフローだ、シミュレーションだ、BAMだなんて言わないでください。そんなものはいわば十徳ナイフのようなものでとりあえず何でも使えるように揃えたので買ってくださいということなので、そこから発想しない方がいいと思います。実際に業務を遂行するのにどんな機能があったらうまくいくのかという見方から発想すべきで、そこからは次のような要件が浮かんできます。

・データを間違わずに登録できる
・登録するデータを確定するあるいは判断を行うときに参考とすべき情報を参照できる
・そのとき、関係する人たちとコミュケーションをしたり、アドバイスをもらったりできる
・データ確定、判断の承認者がはっきりしていて、その人がすばやく責任を持って承認できる
・こうした意思決定単位の進捗(プロセス進行)が監視できる
・プロセスパフォーマンス(時間、期日、手戻り率、スループット)が異常になったら、アラートやガイダンスなどですぐに手を打つことができる
・プロセスを実行した結果がアーカイブされ、必要な時にすぐに取り出すことができる

こんなところではないでしょうか。よく見ていただくとわかると思いますが、自動化という要件が入っていません。例えば、プロセスの進捗を自動的に行うとか、異常になったら自動制御するといったことは特に必要だとは言っていません。もちろん、できればやったらいいと思いますが最初の要件ではないということです。

ということで、上記のような要件をどのようにして、あるいはどの程度まで実現するかが重要なポイントとなるわけです。一般的には、お金をかければ実現具合は高度化していくのですが、だからといって、やみくもに投資するのは得策ではありません。それは、ITシステム的には高度になるかもしれませんが、コストパフォーマンスはどんどん落ちていくからです。へたすると、かえって余計なこととして邪魔になることもあるかもしれません。

要するに、費用対効果の最適ポイントがあると思うのです。それは、会社の規模とか複雑性(グローバル化度、拠点数、チャネル数など)、IT装備率、あるいは成熟度などにより違ってきます。それについては、現実の姿をながめていると、会社の実態以上に投資し過ぎている会社が多いように個人的には思っています。(役に立たない正しいシステムを作り続けていることにも通じる話です)

つまり、仕事のやり方がまだ原始的で属人的だとか、データベースやルールが整備されていない、ビジネスモデルが社長の頭の中だけにあるとかいった段階なのに高価なパッケージを入れているといった例は数多くあるのではないでしょうか。ですから、ここで言っているカジュアルBPMは、もう少し実効的で最適なコストパフォーマンスを発揮できる可能性を追求しようという試みでもあるのです。

データを確定するための仕掛けの現状

前回にカジュアルBPMを実行するための要件について議論しましたが、そこであげたような要件を満たしてくれるソフトウエアなり、パッケージはあるのでしょうか。どうも世の中にはないように思います。また、そうしたシステムをスクラッチで作ったというのもあまり聞きません。ひょっとすると大手ベンダーが提供する大変高価とアドオンするようなツールにはあるかもしれませんが、ここでは対象にしないのでそう言っているのです。

データ登録というとデータベースソフトだし、プロセスエンジンというとBPMSだし、コラボレーションの場というとメールや掲示板だったり、パフォーマンス分析だとBIだったりします。こうして見ていくとそれぞれが帯に短したすきに長しといった感じは否めません。その中でも一番近いのがBPMSなのですが、まだプロセスの自動化の意味合いが強く、そのことがBPMのIT的側面での弱さを表していると思うのです。

ひとつのソフトウエアあるいはパッケージで実現できないとなると、カジュアルBPMでは大掛かりにスクラッチで開発なんてできませんし、高価なツールも使えませんから、出来合いのものを組み合わせるというのが現実的な選択肢となります。

そうなると、少し大胆な言い方をすると、エンジンのないデータベースソフトとマンマシンインターフェースが貧弱なプロセスエンジンのどちらがいいのかになります。そのうち、エンジンをもったデータベースソフトやすばらしいUIをもったプロセスエンジンが登場してくると思いますが、現時点ではこんな選択をせざるを得ません。カジュアルBPMでは前者の方を薦めています。

さて、データベースソフトですが、これはいろいろありますね。ここではDBMSのようなものではなく簡単にアプリケーションが作れてしまうようなものです。例えば、SalesForce、FileMaker、サイボウズデヂエ、Access、Notesといったところでしょうか。これらはプロセスエンジンを持っていない、あくまでデータの登録、検索、閲覧、レポート出力といった機能が主です。

こうした、データの出し入れのアプリケーションはたくさん作られています。例えばSalesForceには、「リード」、「商談」、「取引先」といった機能がありますがどれもが、基本的にはデータを登録して、その結果を一覧表示させ、レポートを出すというものです。ところが、実際の営業活動では、それぞれが独立しているわけではなく、一連の流れとして管理しているはずです。

見込み顧客に対して情報を提供し、見積もりを提示し、交渉して、注文をもらうというプロセスがあって、そこの管理が重要なのだが、単にデータの出し入れだけだとその進捗だとか、どこでてこ入れしたらいいのかといった管理ができないことになります。ですから、プロセスエンジンがあるとそこを順番通りに運んでくれるので進捗はわかるのです。そこで、エンジンがなかったらそこをどうやって代替してやるのかがポイントになってきます。これは次回に。
  
エンジンのない市販のデータベースソフトでもBPMはできる

前回は、これまで議論したようなやり方をそのまま表現してくれるソフトウエアやパッケージがないので、データベースソフトを中心にしていくのか、BPBソフトを使って実現するのかという選択になると言いました。そして、どちらかというと手軽にできるので、データベースソフトを使ってBPMをやったらどうかという提案をしました。

これは実際にある製造系の中小企業でシステム化を行った事例をご紹介しながら見ていきましょう。みなさん、サイボウズデヂエというソフトをご存知でしょうか。サイボウズというのは国産のグループウエアなどを提供している会社で、有名なのはサイボウズOfficeですが、製品のひとつに「デヂエ」という“かんたんWebデータベース”があります。このソフトを使ってシステム作った例です。

実はこの事例のいきさつとしては、元々は上流の業務プロセスの見える化を行ったわけです。プロセス参照モデルをベースに現状の業務を分析して、そこからのビジネス要求を抽出して、そうした課題を解決するための新たな業務プロセスを描きだしました。

具体的には、リーマンショック以来売上げの低下から業績が低迷していて、それを回復させるべく、汎用品の生産から利益率の高い特注品へとシフトすることが課題となって出てきました。しかし、特注品となると顧客要求から設計が入って見積もりを提出して受注につなげるというプロセスをきちんとしないといけないことがわかってきます。

こうして、重点となるプロセスとして、顧客要求から製品仕様設計、原価計算などを経て見積りを提示するプロセスに焦点を当てることにしたわけですが、リファレンスモデルを当て込むまではできるのですが、難しいのはそれをどう実装するかです。まずは、その会社の実態にあったように分解と合成を行い、その会社に合った新たな業務プロセスを導き出します。

さて、実装ですが、このシリーズでも再三言っているようにIT化することがシステム化ではないので、アクティビティの中のデータ確定をどうやってやるのか、そのアクティビティの進捗をどうみていくのかという、要するにオペレーションの観点から吟味しました。

そして、データ確定のところはデータベースソフトがまさにうってつけです。個々のアクティビティをライブラリーという形におとしていきます。ただし、まだデータ登録という考えかたでできていますから、参照情報へのアクセス、コラボレーションの場という面では十分ではありませんでした。それでも、泥臭く手作業でとか、あるいは同じサイボウズの製品の「サイボウズガルーン」と連携してある程度の機能が実現できました。

ここで、悩ましいのはライブラリーの中の確定データを単一にすべきか複数でもいいのかという問題があります。できれば、1ライブラリーで1確定データというふうにして、それを順番に回していくのがいのですが、現実の業務ではそう簡単にはいきません。

行ったり来たりしたり、あるいは合わせ技で決めるとかいったことが起きます。具体的な例でいうと、ある初めてのお客さんから見積依頼が来ると、与信チェックをするわけですが、その顧客との直接取引だと与信に引っかかってしまう。しかし、代理店をかますとOKだとかいったことがあります。

つまり、与信チェックと販売チャネル選択を合わせて判断するわけです。こうした場合は分けてしまって分岐を作るより、同時に複数のことを一つのライブラリー内で決定するという作りにしました。こうした柔軟性のある対応をするというのもカジュアルBPMの考え方です。なぜこうしたことができるかというと、意思決定することが重要なのであって、その決め方を固定せず(プログラムで書かないで)、情報共有空間のコミュニケーションでやればいいからです。

さてそうなると、つぎの問題は進捗管理をどうするかですが、それは次回に。
  
自動化しなくてもプロセス管理はできる

前回、一般的なデータベースソフトを使って、そのデータ登録ライブラリーを意思決定の場として機能させることを提案しました。意思決定の場というのは、簡単に言うとデータを確定する、あるいはある判断を行うような場合に、必要となる情報にアクセスして、その情報を参照し、また関係者と相談したり、助言をもらったりといったコミュニケーションをしながら意思決定ができることを要求します。

一般的なデータベースソフトは、データを入力することが主となっていますので、今言ったような機能は十分ではありません。それでも、データのリレーションだったり、リンクといったこともできますし、グループウエアなどとの連携も役に立ちますのでかろうじて要求を満たすことができます。

さて次は、プロセス進捗管理をどうやって実現するのかになります。プロセスはアクティビティ(単位意思決定)の連鎖ですから、あるアクティビティが完了したら、それを次に動くアクティビティに教えてやらなくてはいけません。該当するアクティビティはああ自分のところに来たなとわかったら、そのアクティビティに相当するライブラリーを開くことになります。

そして、データ確定、判断を行い同じように次のアクティビティ順繰りに送っていくわけです。これが、自動的にやっているのがプロセスエンジンです。ですから、自動的にプロセスを回そうと思うと、当たり前ですが、プロセスフローをちゃんと書かないといけないのです。

ところが、ここで難しいのはきっちりと決められるものばかりとは限らないことです。そんな時どうするかというと、分岐や差し戻しの回路を作ります。これが業務フローを複雑にしわかりにくくする場合が多くあります。このあたりはまた別に議論していきます。

カジュアルBPMでは、立派なプロセスエンジンは使えませんので、まずは全自動化はあきらめます。そんな簡単にあきらめていいのかというツッコミがきそうですが、費用対効果とシンプル性の問題からかまわないと考えています。つまり、高価なツールを入れる費用と便益が見合わないのである。

ではどうしたらいいのでしょうか。自動化できないということは手動でやることを意味しています。今回の事例では、プロセス進捗用のライブラリーを用意しました。このライブラリーというのはデータベースソフトですから、フィールドとレコードという縦横関係表が基本になります。そこで、フィールドにアクティビティ名を置いて、レコードにはステータスを入れることにしました。

ステータスというのは、完了、仕掛中、待機中といったものが入れられます。データの登録が終わって承認されたら、進捗ライブラリーにあるデータ登録フィールドに完了と入れるということです。そして、そのステータスで色を変えて進捗が視覚的にわかりやすいような工夫をします。実はこれでもかなりの効果を生む仕組みと仕掛けになっています。

割と簡単にできると思いませんか。普段、事務所のホワイトボードに書いて管理しているのと基本的には同じです。ただ、それだと事務所以外のところにいる人は見ることができないのと記録に残らないのです。ですから、情報が共有化され、データがアーカイブされることの意義は大きいのです。自動化する意味はそれほど大きくないことがおわかりになったでしょうか。
  
カジュアルBPMのめざすところ

前回までで、一般的なデータベースソフトを使ってBPMの仕組みと仕掛けを作った事例をご紹介しました。この会社ではもともとサイボウズデヂエとガルーンは導入済みで一部使ってはいましたが、もちろんここでご紹介したような使い方はしていなくて、孤立した単なるデータベースでしか利用していませんでした。

ですから、開発の費用は私のコンサル料はともかくとして、社長が自らインプリしてしまいましたから、せいぜいライブラリー数が増えたので月額に費用がちょっと上がったくらいでできてしまいました。

ただし、元の機能から拡張した使い方をしていますから、十分でない、あるいはできない機能もあるのは確かです。その辺のところを考えてみるのと、逆に良さのようなものを考察してみようと思います。

データを確定するためのアクティビティライブラリーでは、基本要求機能として、参照情報アクセスの容易さ、コミュニケーション機能になりますが、ここが参照情報のあるURLをコピペしなくてはいけないとかまだ弱いし、ガルーンという別ソフトの掲示板に頼っているところもあるので、基本装備したいところですね。

それと、この中にワークフロー的な要素を入れたいのです。すなわち、起案―調整―確定―承認という流れなのですが、厳密に順序を管理する必要はありませんが、ロールとか意識させることと承認ボタンはつけたいですね。そのボタンが、アクティビティの完了シグナルになるわけです。

プロセス進捗ライブラリーでは、今言ったようにアクティビティライブラリーで承認ボタンが押されると自動的にここ飛んできて、該当するフィールドのステータスを変えて、色も変えたい。そして、そこから、グループウエアのToDoリストに(ない場合はメールで)次のアクティビティの処理を表示させたいのである。

半自動化と呼べるものだと思うのだが、プロセスの進行をワンステップずつ人間が意識してやるという意味である。このことは、全自動で何だかわからないうちにプロセスが進んでいるというのは気持ち悪いと思うので、こうした半自動化で十分だと思う。

さて、ここで分岐のことに触れておきます。今までの説明で分岐が発生したどうするのだという疑問がわいてくると思います。分岐というのは、プロセス進捗ライブラリーにおけるフィールドの分岐とアクティビティライブラリーにおける確認や承認の分岐の2種類があります。

先に後者のことをいうとここでは情報共有空間でコミュケーションしながら行ったり来たりしてやりましょうといっていて、ワークフローを明確に書きませんから自ずと分岐は発生しません。このレベルではケースバイケースで決まった経路は書きにくいのはお分かりだと思います。調整とか確認なんてあいまいな行為ですから、定型化できないから、いっそのこと自由にやって結果だけを厳密にしようという考え方になります。そのかわり、そのやり取りは記録に残しておくのは必須です。

さて、前者の方になりますが、一番簡単なのは、分岐があるようなら初めから別プロセスにしてしまうという手があります。例えば、商品のタイプによってやり方が違ってくるような場合は、商品の形態で分岐させるのではなく、商品タイプごとのプロセスにしてしまうことが考えられます。

ただ、そう簡単ではなくて、よくあるのは、前のアクティビティの結果によって次の判断が変わるとか、アクティビティ間で行ったり来たりしてからデータが確定されるといったケースがあります。そんな時は、アクティビティを合成してしまうということも考えられます。つまり、二つのアクティビティを一つにして同時に複数のデータを確定しまうのである。

プロセスに分岐があることで、フローが見えにくくなったり、オペレーションが複雑化したりする可能性があるので極力分岐は作らないというのがカジュアルBPMの重要な方針です。
  
すぐに動かすことの重要さ

カジュアルBPMでは市販の一般的なソフト上をうまく使ってやったらという提案をしています。これは、思想にあったツールがないということもあり、しかたなしに使っているという面はなきにしもあらずなのですが、積極的に評価できるところもあります。

それは、すぐに動くということです。テストも要りませんし、デバッグする必要もありません。単体ではちゃんと動くことが保証されているのです。このことは非常に大きいアドバンテージではないでしょうか。スクラッチで開発しようものなら、仕様変更対応からデバッギング、テストとそれだけ疲れてしまいそうです。

ですから、最も重要なオペレーションテストに時間が取れずに中途半端なかたちで本番稼動させてそこで混乱するといったことが起きてしまいます。それを防ぐには、実際に動くものをみて、触ってもらって、それを道具として業務運用に使える実感を持ってもらうことが重要なのです。

ご紹介した事例では、ああじゃないこうじゃないと言いながら、作り動かしてみて、ダメならすぐにその場で修正してという繰り返しで完成させています。少なくともウオーターホールではありませんし、アジャイルってよく知りませんが、それも越えているように思います。こうした作り方ですから、だいたい完成してみんなでレビューするとすぐに使えるようになります。現に同じ事例で、社長がこんな作りになったけどどうかなと言ったら、営業部長と技術リーダはじゃあ明日から使いましょうと言ったのには驚きました。

やはり、システム構築の要点はいかに早い段階ででき上がりのイメージを持てること、それをみんなが共有して、組織活動の道具として有効であるという実感を持つことが非常に大事なことだと思います。それが、パッケージ開発も含めた従来のやり方だと、ユーザが要求を出して、それをシステムサイドが受けて、システムに落とすための要件定義をします。

そこで、分けがわからないのだが、機能要求だとか非機能要求だとかに分けたりして、そこからコードを書き出すわけです。そしてできたものをみると最初の要求と違ったり、反映されていなかったりする。これでは時間がかかるし、非効率的で高コストになります。何と言ってもビジネスの変化についていけません。

今の時代は、経営者の気持ちとしては、新しいビジネスモデルを作ったらすぐにそれをオペレーションしてくれと思っているはずである。それをITがついて行けないので待って下さいとは言いたくないですよね。

ビジネスサイドの要求は単純です。ITでもITじゃなくてもいいから早く効率的で質の高い業務オペレーションをしたいだけです。機能要求も非機能要求もどうでもいいのです。非機能要求なんてソフトウエアが持っていてくれよという話なのである。システム構築をもうちょっとシンプルに考えていきたいものである。
  
おわりに

いよいよこのシリーズも最終回です。最初に、BPMをもっと気軽に、そして気楽に普段着を着る感じでできないかという提案をして、その実践をどうやってやったらいいのかを事例を混じえて書いてきましたがいかがでしたでしょうか。

カジュアルというといいかげんでもいいような気がしてしまいますが、実は理解してほしいのは、カジュアルはベースがしっかりしているからこそできるということです。基本のところがきちんとしてぶれないようにして、そこの上に表現するものは、わりと緩やかで自由にやるという考え方です。

ここが非常に重要なポイントです。どんな構造体も全部が堅牢にあるいは固定されたものだけで作られているわけではなく、柔軟で変動的なものとのバランスでできているといえます。堅牢で固定的なものを何にするのか、柔軟で変動的なものを何にするのかをよく吟味して適切に配置することが大事になります。

では、カジュアルBPMにおける堅牢で固定的なものは何でしょうか。それは、プロセス設計のところです。つまり、ITとか見栄えとかではなく、ビジネとの一貫性、連動性を失わない業務オペレーションができるよう設計された仕組みと仕掛けです。ここをしっかりと作れるかにかかっています。堅牢で固定的ということは汎用化、標準化できるということも意味しています。言い換えると、汎用化、標準化できる粒度、レベルで作っておくということです。

具体的に言うと、プロセスの始点と終点が何で、その間にある意思決定はどんなものがあって、それを誰が責任もつのか、その意思決定のために必要な情報には何があって、どんなパフォーマンスを制御するのかといったことを記述することがベースなのです。

それさえちゃんと記述できれば、極端な話、あとはITを使おうが手作業でやろうが、ひとりで何役をこなそうがかまわないのです。そこのところは、柔軟で変動的なものと考えるわけです。例えば、プロセスの進捗をホワイトボードに書いてもいいし、顧客情報がバインダーで閉じられた紙でもいいのです。自分たちがやりやすい、あるいはお金が出せる範囲で徐々にやっていけばいいのです。

このシリーズで一番言いたいのはこのことで、経営とITの融合なんて言いながらいつのまにか戦略やビジネス要求が吹っ飛んでしまったITシステムをつくり、お金をかければりっぱなシステムになると思っている間違いを正したいのです。またいろいろと実績を積み、ブラッシュアップできたら報告することにします。
 

About 2011年8月

2011年8月にブログ「mark-wada blog」に投稿されたすべてのエントリーです。新しい順に並んでいます。

前のアーカイブは2011年3月です。

次のアーカイブは2011年9月です。

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

Powered by
Movable Type