メイン

ユーザ目線のBPM アーカイブ

2007年2月27日

ユーザ目線のBPM

今日から、「ユーザ目線のBPM」というタイトルで、ユーザの目で見た企業の情報システムはどうあるべきかについて、BPM(Business Process Management)という切り口で書いていく。

議論のフレームは、前提として、現在の企業の情報システムのあり方に問題があって、それを解決するのにBPMが有効な手段になりそうなので、それはどのような体系、方法論、テクノロジーであれば有効であるのかを議論することにある。

さらに、単に勉強するだとか体系だけ作っておしまいということではなく、実践の場や実行スキームなどの方策も指し示すことも行っていく。システムは作って何ぼ。いやユーザの役に立って何ぼの世界であることを肝に銘じて論を進めていく。

また、議論は業務アプリケーションの構築という領域に絞っている。従って、システム基盤や運用といったところには言及していない。

具体的には、 ユーザに役立つシステムにシステムにするためには

・どんな構造の仕組みがいいのか

・それをいかに早く作れるのか、変更できるのか

という観点でいろいろな角度から検討する。

ユーザ目線のBPM (1)

ユーザのためのシステムを作るんですよね

第1回目は、誰のためのシステムなのかということから始める。こんなことは皆当たり前に分かっているとお思いでしょうが、実は、勘違いも含めて、え、そんなことも分かってないのということがある。

最近、ある二つのカンファレンスに出席してみて感じたことが、そのあたりの状況を見てとれる。それは、「Developers Summit 2007」と「経営とITの融合(KIU)」研究会主催の「第1回 アジャイル・エンタープライズ・カンファレンス」で前者はソフト開発者の集まりで、参加者の多くがプログラマーやSEの若い人たちであり、後者はどちらかというと企業の情シ部門の人だとかSIベンダーのコンサルタントの人だとか、比較的年配が多いカンファレンスであった。

簡単にいえば、システム開発というのは、ユーザとSIベンダーのコンサル・SEとソフトハウスのプログラマーという三者の協業で作られる。この場合、企業の情報システム部門はユーザなのかSIベンダーなのかだが、そこは、情報システム子会社も含めてSIベンダーのほうに入れて考えたほうがよいだろう。そういう意味では、「Developers Summit 2007」プログラマー主体、「第1回 アジャイル・エンタープライズ・カンファレンス」はコンサル・SE主体であり、ユーザの参加は少なかったように思える。

そこで感じたことは、この三者の間のギャップなのです。別な言い方をすれば、システム開発の上流設計から製造までのプロセスが分断されているというか、うまく受け渡しがなされていないように思える。

要件定義は、経営戦略的にこうすべきだから、そのためのビジネスのゴールを設定して、それが実現できるように仕様を決めていくべきだと言われても、それはあくまでSIベンダーサイドの言い分であって、ユーザは本当にそう思っているの、ユーザのプロジェクト担当者だけ思っていることではないのとツッコミたくなる。

また、開発者サイドも自分たちの得意エリヤで、自分たち独特の言い回しで、自分たちだけで楽しむという一種のムラ意識があるように感じる。彼らのセッションでは出席者から「アウエーの雰囲気だったけど・・・」というような言葉も出てくる。どうも上流のビジネスプロセスがどうのこうのということに興味がないようだ。

ユーザからみると困ったもので、このギャップを埋めて欲しいと願っている。ただそれがすぐにできるとは思えない。なぜなら、本質的なあるいは構造的なといったほうがいいかもしれないがそういう問題が潜んでいる。

どういうことかと言うと、ユーザとSIベンダーとの間で言えば、両者の利益が相反するということが一番大きい。SIべンダーは自分たちの商品が売れればいいし、開発にかかった工数分の費用がもらえればいいのであって、それによってユーザの事業の役に立っただとか、収益に寄与したかなどどうでもいいのだ。実際にどこもがそうやっていると言っているわけではなく、本来的にそういう体質を持っているということなのだ。

開発者の場合について言えば、技術をというか技能といったほうがいいかもしれないが、それを極めるには必然的に足元の世界にのめりこむ。だから、同様にビジネスに貢献するとかという思考回路はあまり働かない。

開発者は無関心、SIベンダーとユーザはお互い嘆きあう構図はもううんざりだ。さて、どうしたらいいんだろう。そこはこれからの議論で追々詰めていくことになるが、少なくとも、「システムとはユーザのためにある」ということはよろしいでしょうな。

それで次回は、そのユーザとは誰のことかというテーマで書こうと思います。

2007年2月28日

ユーザ目線のBPM(2)

ソフトウエア業界の構造的な問題

ユーザとは誰なのかというテーマの前に、少し、SIベンダーとユーザ企業の関係について触れておく。

前回、ユーザとSIベンダーの利益が本来的に相反するということを書いたが、この問題は日本に固有のものであるかもしれない。まず、象徴的な事例を紹介する。世界的なERPベンダーであるSAP社が毎年「SAPPHIRE」いうユーザカンファレンスを開いているけど、アメリカ開催と日本開催で出席者の様相がまるで違う。アメリカでは出席者の7割がユーザなのに対し、日本の場合は7割がITベンダーなのです。ですから、アメリカではセッションでユーザの導入事例やユーザ自身が作ったアドオン機能だとかが多く紹介される。日本では、パートナー企業の売り込み的発表が多い。

日本の場合は、その歴史的な背景を見ておく必要がある。そう長くはない日本のITの歴史で国産メーカのはたした役割は大きく、国の保護の下、IBMの対抗軸として国産メーカは成長していった。当初のビジネスはIBMも含めて高価なハードウエアを販売することが収益の源であり、ソフトウエアはそのおまけとしてただ同然で提供された。

同じように、システム開発もハードウエア費用に隠れて、極端な話、いったいいくらだったのか分からないということもあったようだ。こうした関係であれば、ユーザは必然的にメーカにおまかせすることが最良の選択となる。この関係がいまだに続いているように思える。ですから、ユーザ自身の自立化という課題も厳然とあるのです。

まかされた側はどうなるか。ユーザがどうのこうのじゃなくて、確実に動くシステムを正しい方法で手間ひまかけて作り上げ、それにかかった費用はいただきますということになる。ユーザもITのことはよく分からないので反論もできず、高い金を払うという構図ができあがる。

もう、こんなことはやめようという声もあがっているようだが、ユーザが立ち上がっていない。そこで、情報システム部門やユーザ系情報子会社がユーザの立場になって考えることが必要になってくるが、ここがまた弱いのだ。中途半端になっている。ユーザの業務をよく知っているかと言うと、自社システムに乗っている仕組みは知っているが、例えば、なぜその業務があるのかとか、システム以外の業務はどうしているのかとか、分からないのだ。また、ITの本当のプロにもなりきれない。だから、前回に書いたように情報システム部門やユーザ系情報子会社は、どちらかというとSIベンダー側に寄せている。

結局、今後デブサミ2007で中谷多哉子氏がいみじくも言っていた「役に立たない正しいシステムを作るのは、もうやめましょう」ということになる。それには、ここで言っているような構造的な問題を改革することも重要なことである。


2007年3月 1日

ユーザ目線のBPM(3)

ユーザとは誰のこと、そして何を考えているのか

ひと言でユーザといっても様々である。ひとによってはユーザ企業と言ったり、ベンダーにとっては自分たちの顧客企業だったりします。しかし、この括りだとあまりにも広すぎて、どんなものが欲しがっているのだとか、どういうサービスを提供したらいいかなど考えたとき絞りきれないことになる。そうすると、「システムを使う人」をユーザと呼んだほうがよさそうだ。

そういった観点から、企業の中で働いているひとを分類してみると、大きく、経営者(社長)、事業責任者(事業部長)、業務遂行責任者(部長、リーダ)、業務担当者ぐらいに分けられる。経営者は事業部長に事業の執行を負託し、事業部長はそこの部長やグループリーダに対し、事業運営上必要な業務プロセスを正確にかつ効率的に廻すことを指示し、部長やグループリーダは自分の部下ある担当者にオペレーションを実行させる。この役割をはたすために必要に応じシステムを使うひとたちがユーザということになる。

これは、主としてライン組織のことを言っているので、このほかにスタッフを入れてもいいが、システム的にはスタッフ業務のような不定形な支援業務は外して考えてもかまわないので、ここではライン組織にいるひとたちをユーザと呼ぶことにする。

いま、こうして言っていることは上場しているような企業を対象としているが、中小企業の場合は、経営者ひとりがほとんどの役割を持っている。

それでは、それぞれの立場のひとたちは、どのようにシステムを使うのだろうか。また、システムあるいはITに関して何を考えているのだろうか。

まずは、経営者についてみてみよう。経営者はITをどのように使い、その有用性をどう考えているのだろうか。実際の経営者との会話の中で語られたことを今から述べる。

ある時期危機に瀕していた会社を立て直し、中興の祖と言われたような立派な経営者のひとが、あるとき、会社の経営について語ったのだが、しみじみ「経営の歴史というのは、特別損失の歴史なんだ」と言った言葉がすごく印象的であった。

ひとつには、日々努力して積み上げたものが一瞬で消し飛んでしまう恐ろしさであり、また、ひとつの会社のことだけの問題ではなく、社会の一員であるの会社として、その社会環境の大きなうねりの中にいて、いつその波をかぶるかもしれない、そんな中での営みが経営でもあるということを言いたかったと思う。環境問題、事故、ファイナンスの失敗、海外プロジェクトの政治的リスク、合併、コンプライアンス等々、こうした問題で損失を被ることの経営に対するインパクトは大きい。

このような問題に対しITが貢献できるかと考えたとき、何があるのだろうか思ってしまう。ITで危険予知情報を流すことができるじゃないか、みたいに言われるが、本当に役に立つ情報を探し出して提供できるのだろうか。内部の財務データや与信データぐらいはできるかもしれないが、外部についてはおそらく難しいと思うし、経営者も欲してはいないだろう。

また、だいぶ前だがあるセミナーのパネルデスカッションで言ったこともユーザのITに対する考え方につながる話なので、ここで紹介しておく。それは、情報活用についての各社の取り組みを議論というより、紹介し合うようなものでしたが、そのパネラーとして参加して発言したことを少し長くなるが引用する。

情報活用行う上で重要なことがありますそれは3つの度ということです

1、3つの度とは、鮮度・感度・加工度
2、感度というのは情報の送り手と受けての意識がどれだけマッチングしているか、受け手の期待と送り手の洞察力が合うかどうか 
3.加工度というのが結構大事なことで、どういうことかというと、あるとき経営トップと話をしていたとき、事業部などとのヒアリングで分厚い資料を見せられて、どうかといわれるが、そのデータというのはたいていの場合自分たちの都合のいいように加工したもので恣意的なデータであるわけで、そんなものをみせられても困る。いっそ生のデータのほうがましだと言われたことがありまして、しかしだからといって生のデータを渡してどうですかというわけには行かない。どこまでに加工するかが重要なポイントではないか。

では経営に役立たせるためにはどんな情報を提供すべきなのだろうか
1、いまのような話となると、経営としては単なる数値データだけの情報ではもちろんダメ
2、数値データではない情報、内部情報だけではない外部情報も必要
3.死体解剖的な情報から生体ドック的な情報をどう提供できるかにかかっている
  過去のデータみてどうだったかではなく、これからどういう手を打つんだというための情報が重要
4.究極的な言い方をすると社長になれるCIOがどんどん出てこないと真に経営に役立つITを提供できない

ところが役に立つ領域もあって
1、情報活用を考えるとむしろ事業部長とか各部長のところが有効
2、なぜかというとちょうど情報がクロスするところで、経営からの情報、オペレーショナルレベルからの情報がクロスするところ
3、ここの裁き方で企業としての情報活用度が上がる
4.したがって、ここへ向けた仕組みを構築するのが効果的

というようなことをしゃべった。要するに、「経営に貢献するIT」なんて軽々しく言えないなということである。

ですから、大上段に振りかぶって経営戦略がどうのこうのといわず、“会社の業務がちゃんと動く骨太の基本構造をシステム化すること”が最重要で、それは、業務プロセスとそれに情報活用でオペレータやマネージメントを支援するシステムがあれば十分であると思う。オペレーショナルなレベルに近いところのシステム化ということである。

ですから、別の言い方をすると、事業部長や部長クラスのミドルマネジメントにとってはITは非常に有用なツールであると言える。

稚拙なたとえ話で恐縮ですが、経営者は性能のいい車と腕の立つ運転手だけがほしいのであって、自分の行きたいところに自分の思ったように運んでもらえばいいと考えている。余計な機能、例えばスピードが出ているから緩めろとか、この道が早いからこちらを通れとか、それこそもうすぐレストランだからそこで食事せよとか言ってくれるなと思っている。寄り道したいときもあるし、たまにはスピードも出してみたいときだってあるのだ。それは、経営者の頭のなかにあって、それが経営者のシステムなのだ。

よく、えらそうに小声でこれはすごい秘密情報だから、ここだけの話にしておいてくれ、とかさも自分は会社の中枢にいるえらい人かのように言う、まあだいたい中間管理職だがそういうひとがけっこういる。ところが良く考えてみるとそんなものはほとんど秘密情報でもないことが多い。もちろん、新商品の情報とかの本当に秘密にしなくてはいけない情報はあるが、最近はどんどん情報開示の方向であり、かなり少なくなってきている。

それで、その辺を喝破した経営者がいた。曰く「会社の秘密情報は全部オレの頭のなかにある」。そうなのです、最後の最後にどんでん返しとなる企業合併なんか典型です。

ということで、性能のいい車とカーナビくらいを用意しましょうというのがここで言いたいことです。

2007年3月 2日

ユーザ目線のBPM(4)

ユーザと作り手とのギャップ解消の方向性

前回、ユーザの望んでいるシステムはどんなものであるかを示したが、そこでは“会社の業務がちゃんと動く骨太の基本構造をシステム化すること”が重要であると言った。そんなことは、すでにやっているし、できているとみな言うのじゃないか思うが、“ちゃんと動く”ということと、“骨太の基本構造”というところがミソで、ここがほんとうにできている企業は少ないのではないでしょうか。そこを考えていこうと思います。

それには、ユーザとシステムの作り手がうまくコラボレーションしてやれているのかという問題と、システム開発の道具とそれによって作られたシステムの構造の問題が潜んでいると思う。

ここでは、前者のコラボレーションの問題について議論する。

“ちゃんと動く”ということは、ユーザの要求と作り手側の要求実現度と最適化レベルが両者のコラボレーションで行われていることが前提だ。

もう少し噛み砕いて言うと、ユーザはまずは現状の業務をベースにシステムを考える。いわゆるAsIsモデルがまずありきで、そこに今困っていることや変えたいことをそこに反映していこうと通常考えます。ただしこれだけで、あるべき姿ToBeモデルができるわけではありません。

そこで、作り手側の登場です。作り手側は、技術的に要求どおりできないことがあったり、運用上やめたほうがよいことなどが出てきます、こうしたできないことは反映しないと言うわけです。この反映のされ方が要求実現度です。ここを無理だ無理だと撥ねつけるのではなく何とか実現してあげたいとすることもあるし、逆にユーザもシステム技術上の無理難題を押し付けることはしてはいけません。このコミュニケーションが大事です。

そして、作り手側は技術的な観点から、こうしたほうがよいとか、こんなこともできますよという積極的なアドバイスをする役割を担っています。今日、この技術ドリブン発想は重要なことです。

システム開発というのは、家作りとか自動車作りに例えられることがありますが、決定的に違うのは使う人が技術が見えないことだと思う。家や車を買う人は何となくどんな部品でどんな技術で作られているのがわかっているのと、作る前に出来上がりイメージがだいたいできるが、システム開発の場合は、使う人はプログラムソース見たって全く分からないし、出来上がってみて初めてこのシステムってこんな風に動くのか分かったとか、そんなことになる。従って、技術を理解している人がきちんとそこを説明し、技術の活かし方や使い方を提案することが、プロのシステム屋のやることではないでしょうか。こうした、相互の歩み寄りで最適化が可能になるのです。

今はそこのところがどうなっているかというと、ユーザに言われたとおり作るか、システムの分からないユーザに意味不明の三文字熟語を並べ、極端な話勝手にシステムを作ってしまう、いわば両極端のケースが多いのではないでしょうか。

これからはこの中間のアプローチが必要で、そのためにはユーザと開発者(この場合はプログラム製造の領域近い)の距離を縮めることをしていかなくてはいけません。それができるのは、中間にいるコンサル、SEなどですから、そこを埋めていく努力をして欲しいわけですが、実際にはうまくできていないように思われます。

「ユーザがその業務、事業をスムーズに実行できるシステムを開発すること」をめざすのではなく、「ユーザがそのシステムを使って自分たちの業務、事業をスムーズに実行できること」をめざすという、この微妙な違いを理解する必要がある。

で、こうしたコラボレーションをベースとしたシステム開発の進め方でぜひ採用して欲しい考え方がある。それは「デザイン思考」という考え方で、そこにある「創造のプロセス」は、システム開発の場でも十分適用できるものである。

これは、慶応大学環境情報学部の奥出直人教授が提案していて、実際に企業のイノベーションを起すための方法論として注目されている。最近、「デザイン思考の道具箱」という本を早川書房から上梓しているので、その中から、基本的な概念を紹介する。

プロセスは全部で7つのステップから成っている。

ステップ1 哲学とビジョンを構築する
ステップ2 技術の棚卸とフィールドワーク
ステップ3 コンセプト/モデルの構築
ステップ4 デザイン- デモンストレーション用プロトタイプをデザインする
ステップ5 実証
ステップ6 ビジネスモデル構築
ステップ7 ビジネスオペレーション

こうしたプロセスは、まさにこれからのシステム開発のあり方に多くの示唆を与えてくれる考え方であると言える。次回にこの詳細について述べる。要は、ユーザや開発者が一緒になってシステムをデザインしていこうじゃないか、それが役に立つシステムを作ることにつながるということが今回言いたかったことです。


2007年3月 3日

ユーザ目線のBPM(5)

システムをデザインする

それでは、奥出直人の言う「デザイン思考による創造のプロセス」にもとづき、情報システムの開発について考えてみることにする。

「デザイン思考による創造のプロセス」とは、“社会的背景や哲学的背景を踏まえた上での考え方、作り手の問題意識を表わす哲学を考えるところから始めて、具体的に何を作りたいかビジョンを決め、それを持ってフィールドワークに行き、どのようなものを作るかコンセプト/モデルを作り、機能やインタラクションを検討しながら実際の設計デザインを行い、実証する。つぎにビジネスモデルを構築して、実際の運営方法を決定する”プロセスのことと言っている。

そのそれぞれのステップについて追いかけるが、より重要なプロセスとして上流のプロセスの最後であるデザインするところまでを取り上げる。

まず、ステップ1「哲学とビジョンを構築する」ことだが、企業の情報システムであれば、会社の経営理念や方針あるいはもう少し狭くて部門の運営方針といったものが哲学やビジョンに相当する。さらに、最近よく言われるEA(Enterprise Architecture)もこれにあたるものである。

ついで、ステップ2「技術の棚卸とフィールドワーク」は、従来の方法では、ビジョンからすぐにコンセプトへとつなげるが、ビジョンとコンセプトを明確に分け、この二つをつなぐ作業として位置づけられる。この考えが非常に重要である。

技術の棚卸しとは、アイデアや技術をたくさん集めて並べ、それをビジョンに割り振ってみるやり方であり、フィールドワークとは、ビジョンに基づき自分のビジョンを実現してくれるだろう「師匠」のところに出かけ、弟子入りし、みずからの経験を拡大していく、その記録を分析して「ワークモデル化」した段階で「魔法のシナリオ」と呼ばれるものを書く作業を行なう。「初心者であることは素晴らしい。それは自分の知らないことを知って、驚き、不思議に思う、その差分が価値を生むからだ」ということである。

これを、システム開発にあてはめてみると、いわゆる現場ヒアリングという行為に相当するかもしれない。しかし、いま実際にやられているのは単に現状業務の手順や問題点を聞いているだけで、ビジョンをきちんと確立してから行っているわけではないし、そもそもデザインするというマインドを持っていないと言える。ここは非常に重要なポイントで、ユーザニーズを聞くということももちろん大切だが、実現したいビジョンを頭の中に入れて、そのために現場のエキスパートをよく観察して分析する姿勢が肝要である。

ステップ3はいよいよ「コンセプト/モデルの構築」に入る。コンセプトというのは、アイデアをいくつか組合わせて、具体的にどのような技術でそれが可能になるかを検討していき、そこで生まれたビジョンを実現するための具体的な方法とその構造をいう。なおコンセプトには技術の裏打ちが絶対必要であることを忘れてはいけない。そのコンセプトを実現するための基本構造や仕組みを選んだり作りだしたりする作業を「モデル」を作るあるいは探すと呼ぶ。

そしてダーティプロトタイプあるいはラピッドプロトタイプと呼ばれる原初的なプロトタイプを作っていく。このあたりのやり方は、システム開発でいうプロトタイピング手法であるが、この場合はコンセプト形成はやってない場合が多く、しかもプロトタイプというとどちらかと言うと画面や帳票といったユーザインタフェースが中心で、システムの構造やプロセスの動きなどは分からないため、ここでいうステップの作業とはずいぶんと違う。

これからの開発で必要なのは、システム全体が見渡せるプロトタイプができる道具が要るということ、その道具は簡単に安く作れ、ラフなものからだんだん精巧なものへ進化させることができ、それを皆で議論しながらやっていける、そんなものが欲しいのだ。プロセスモデラーやシミュレーターみたなものが機能を追加すればこれにあてることができる可能性がある。

また、コンセプトの一部はEAから引用してくることができる。 このステップでおおかたのシステムの構造やプロセスの骨格が決まってくる。

上流プロセスの最後は、ステップ4「デザイン- デモンストレーション用プロトタイプをデザインする」である。デザインとは、機能を考えながら必要な要素を集め、構造や仕組みをつくっていく作業である。

これは、まさにコンポーネント開発に他ならないのではないでしょうか。そして、大事なのは、見えるもの(プロトタイプ)を早く作ってそれを見ながらデザインしていくということである。

こうしてみていくと、「デザイン思考」ということが、情報システムの開発にも適用できる、いやこうした思考方法が非常に重要であることがわかると思う。

なお、デザイン思考を活用するために使いこなすべき道具として、「経験の拡大」「プロトタイプ思考(build to think)」「コラボレーション」の3つを上げている。

この3つについて簡単に言えば、「経験の拡大」とは現場の人間の動きをよく観察せよということであり、「プロトタイプ思考」は見えるものを実際に作りながらスパイラルアップして行こうというものであり、同じ言葉が話せる精鋭による「コラボレーション」で作業することと理解できる。

今回は、「デザイン思考」によるシステム開発プロセスの有効性について書いたが、実際のワークモデルなどより具体的な手法の話まではここでは言及しない。なお、次回は、道具としてのBPMの可能性について考える。

2007年3月 5日

ユーザ目線のBPM(6)

SAPの変化を見ると分かってくること

これまで、Whyと上位概念としてのHowを中心に、本当にユーザに役立つシステムを作らなければいけないこと、そのためにはユーザと作り手が一緒になってシステムをデザインするという思考が大事であるというようなこと議論した。

ここからは、どんな構造のシステムを作るのか、それをどんなMethodologyや道具を用いるのかというWhatとHowについて論じていくことにする。

まず、「道具としてのBPMの可能性」の前に、企業情報システムの変遷をみてみる。ここで教科書に書いてあるようなことを言ってもおもしろくないので、世界最大のERPであるSAPの変化の過程(SAPは進化と言っているが)を例に考える。

SAPのERPは現在「mySAP ERP2005」というのが最新バージョンであるが、その前1992年に投入されたSAP R/3というのが有名でこれによって大きく普及した。R/3というのは、メインフレームのシステムであったR/2からクライアント・サーバー型に移行したもので、今までばらばらであった基幹業務システムを統合し、システム間の整合性をとることに威力を発揮した。そしてよく言われたのが、バッチからリアルタイムへと変わるということで、その当時、一度入力するとすっと最後まで行ってしまうから入力するとき怖くて手が震えたといった話をしていたことを思い出した。このリアルタイムということには誤解があってそれについては後で述べる。

この時点でのERPの特徴は、統合化、リアルタイム化、標準化(グローバルスタンダード)であった。しかしながら日本ではこのうちリアルタイム性とグローバルスタンダードは合わないため、メインフレームで統合化されたシステムを持っているところは、それほど魅力があったわけではなかった。

そして、つぎに出てきたmySAP ERPで大きくコンセプトを変えることになる。それは、ESA(Enterprise Service Architecture)と呼ばれる、いわばSOAの概念を採り入れたことだ。そして、ポータル、データ連携、BI、マスタデータ管理などのシステム基盤であるNetWeaverをリリースしたのである。このESAのアーキテクチャは非常に重要でこの理解がないといくら新しいERPを入れても無駄だ。

わが国でもいま少しずつ分かってきていると思うが、おそらく本当にここを理解しいているひとは数少ないのではないでしょうか。だからまだ、アドオンをいっぱいして旧来型の作りにしているプロジェクトも多いかもしれない。どこがどう変わったかを検証すると、ここで議論しようとしているシステム開発の方法の参考になる。というか、結局めざすところは一緒なのだということがわかる。

新バージョンの価値をひと言で言うと「情報を起点としたオペレーションと管理」ということになる。すなわち、情報が業務のアクションを誘導することであり(これが最初に言ったリアルタイムということなのだ)、常に事業の状況を監視し、異常が生じたらワーニングする仕組みなのだ。

そのため必要なことは、シンプルで一貫化された業務プロセスでなくてはならないということと、それが可視化されていることが重要である。従来は、この業務プロセスがすでにSAPにあって、それを使えるかどうかと考えるイメージだったと思う。そして、もし自社のプロセスが合わない場合、2つの誤った方向に走ったわけです。ひとつは、無理やりSAPに合わせて窮屈な思いをする。もう一方は、現状システムを生かそうとしてアドオンの嵐となる。

これが新しいSAPの姿では、標準化された機能を組み合わせてプロセスを自社の要件に合わせて組み上げるイメージです。従って、自社のプロセスと機能(機能とプロセスは明確に分離することが肝要)を特定し、業務プロセスを個性化することができるのです。よく、ERPパッケージは要件定義する必要がないように言う人もいるが、このように要件定義が重要なステップになるのです。

「システムの枠組みにプロセスを合わせる」ことから、「プロセスに必要なシステムを組み合わせる」ことに大きく舵を切ったことをよく認識することが必要です。これって、なんかBPMでしょ。そうなのです。SAPの今の姿はSOA基盤に乗っかったBPMシステムなのです。

SAPという会社はこのパッケージだけに多くの人間を抱え、日夜開発にいそしんでいるわけで、それを考えるとIBMより大きな会社とも言えるし、そのシステム開発のトップランナーがこうした方向性を示していることは特筆すべきであろう。

余談になるが、奥出教授の「デザイン思考の道具箱」によれば、SAPの共同創立者であるハッソ・プラットナーはスタンフォード大学のデザインスクールに3500万ドルもの資金を提供して「デザイン思考」の研究を支援しているのだ。SAPの懐の深さを感じる。

2007年3月 6日

ユーザ目線のBPM(7)

Webの世界を見ると分かってくること

SAPのような企業の基幹システムの話とは別に、Webの世界で起きていることを簡単にレビューしておく。

まずはWebサービスという概念であるが、当初はSOAP、WSDL、UDDIというどちらかというと技術的な側面が色濃かったが、近頃ではサービスという意味合いも出てきていて、例えば、GoogleMapsに代表されるように公開されたWeb APIを使ってMashUpされたWebアプリケーションが続々登場しています。

技術的にもSOAP/WSDLに似たRESTなどが出てきて、今後REST準拠のWebサービスが企業のシステムには入り込んでくる可能性もあると思われる。REST(Representational State Transfer)を説明するのはむずかしいのですが、基盤となるアーキテクチャスタイルのひとつで、といっても抽象的でよくわからないので、リソースの状態の表現、例えばヤフーから得られた東京の天気予報などを指しますが、それをサーバーからクライアントに転送することとでも言ったらいいのでしょうか。

GoogleMapsのようなWebサービス以外でも、del.icio.usのようなソーシャルブックマークサービス、flickerのような画像共有サービス、mixiのようなSNSといったサービスも揃ってきました。これらがすぐに企業システムに使われるかというとそうではありませんが、例えば、路線検索サービスが旅費清算システムに組み込まれるといったことは現実になっているわけですから、様々な形のマッシュアップが今後増えてくると考えられます。

マッシュアップは、SAPの説明のときに言った「機能を組み合わせてプロセスを作る」ことと同義であると言えないことはないと思います。

野村直之さんの「Web2.0 for Enterprise」では、超短寿命時代の企業情報システム実現のために採用されるであろう手法について予測している。

(1)「エンタープラーイズ・マッシュアップ」(クライアントサイド)

(2)「XMLDBのスキーマ拡充やミドルウエア」(サーバーサイド)

(3)「軽量言語(Ruby on Rails等)の活用」(比較的小規模なサーバー)

(4)「“軽量”Webサービスやmicroformatsで連携」(必要な部分だけ作る)

これらを見ていくと自前のアプリを簡便な手法でWebサービス化したりして疎結合で安定したシステムを素早く作ろうという方向性が浮かび上がってくる。

業務プロセスのひとつの機能をサービスとみたてれば、これもまさにSOAの基盤の上にのったBPMと言えないこともない。

こうして、SAPとWebの世界を眺めていくと、最近の企業情報システムのあり方が見えてきたのではないでしょうか。そして、これらのアプローチや考え方、さらにはテクノロジーを融合して行こうというのがこの議論の大きなねらいのひとつなのだ。

なお、Web2.0の技術やビジネスモデルにについては後述する。

2007年3月 7日

ユーザ目線のBPM(8)

道具としてのBPM

さて、SOA基盤に乗っかった業務プロセスをデザインするにはどうもBPMがよさそうだということになってきた。でもBPMとは何なんだろう。Business Process Managementというけど業務プロセスをマネジメントするって実はよくわからない。

そこで提案したいのは、BPMのMはMapper/Modeler/MonitorのMであることです。すなわち、業務プロセスをデザインするための道具(これとは別にエンジンとしての機能はもちろんある)と考えてしまったほうがわかりやすい気がするがどうだろう。

Mapperというのは、機能あるいはサービスをマッピングするツール、またはハブとして機能させることである。

Modelerは文字通りモデリングするためのツールで、しかもシミュレーションができることが必要である。このツールを使いモデルを描きながらシンプルで一貫化されたプロセスになっているかを検証していく。このとき、重要な機能として制約条件やルールによるチェックが自動的に行なわれることが望ましい。

例えば、プロセスのひとつの構成要素であるタスク(アクティビティ)のつながりの中で前のタスクのアウトプットが次のタスクのインプットになっているかだとかプロセスに重複業務や迂回業務が発生していないかなどをチェックしてくれて、それに従ってシミュレート(評価)しながら作っていくと、自ずとめざすプロセスができあがるというのが理想的である。

Monitorは業務の動きを監視し、異常の発見をおこなう。ここでは、パフォーマンスの監視というより、むしろ業務の流れの停滞を見つけたり、目標からの乖離などを探る役割である。

どうも、ITに限らないことかもしれませんが、概念的あるいは戦略的なことを大きな声で言う人がいますが、ではそれが実際に実行できるかというと、実は方法論を持っていないことが多いような気がします。

また、素晴らしい方法論でもそれが使えるのはごく限られた天才でしかなかったといったことも起こります。ですから、あるレベルのスキルをもった人(誰でもというのは無理ですが)が、それを使うとだいたいできてしまうという「方法(メソッド)」が必要となります。そのメソッドをBPMと結びつけてパッケージ化できたら素晴らしいと思います。このメソッドについては後でもう少し詳しく議論します。

そして、このパッケージを使いこなし、最適なビジネスプロセスを設計できる人をビジネスプロセス・デザイナー(BPD)と呼びたい。これまで、システムエンジニア(SE)と呼ばれるひとたちがいるが、そのネーミングからいくと、どうもビジネスのことをちょっとおろそかにしているイメージだ。だから、ビジネスエンジニア(BE)と呼んだほうがいいと思っていたが、それでもエンジニアという意味が単にモノを設計する感じとなるので、これからはデザイナーのほうがしっくりいくように思う。


2007年3月 8日

ユーザ目線のBPM(9)

BPM2.0

ここで、米国Intalio社のIsamel Ghalimiというひとのレポートを紹介します。この人はもう6年前にBPMのホワイトペーパーを描いた人でオープンソースベースのBPMSを提供しています。現在も盛んにBPMに関する発言をしていて、BPM2.0なんてことも言い出している。なぜ、ここで紹介するかというと、どちらかというとBPMは道具であるという視点でみているところがあるのであえて彼の意見を載せる。

まず、彼の言うBPM2.0について、Tim O'reillyばりに比較したものを抜粋して示す。

BPM 1.0                          BPM 2.0

Marketed to Business Analysts       Used by Process
Analysts

Starting with a Process Modeling Tool  Starting with
a CompleteBPMS

Multiple Tools from Multiple Vendors   One Single Tool
in Eclipse

BPEL, BPML, WSFL, XLANG, XPDL      BPEL

ARIS, HIM, UML, Proprietary Notations  BPMN

BPEL Editor                   BPMN Designer

Writing Code Behind the Boxes       Zero Code

Writing Deployment Descriptor Files    One Click Deploy

Application Connectors            Generating Web
Services on-the-fly

Bring your own Rule Engine         Rule Engine
Included

Bring your own BAM              Real-Time BAM
ncluded

Ad hoc Process Simulation          Native Process
Simulation

ただ、この中にはBPM1.0と2.0の比較であると必ずしも言えないものや、単に標準化されたことや技術的に集約されたことなども含まれているが、雰囲気的には、Process Design Toolのような感じがしませんか。

さらにおもしろいことを言っていて、

BPM 2.0 is not for non-technical business analysts. We’ll just let more technical process analysts understand business requirements and implement them directly into the process, while leveraging existing IT systems.

BPMは技術を知らないビジネスアナリストのものではなく、プロセスアナリストがビジネス要件を理解して、直接プロセスの設計・開発をしてほしいと言っている。また、

Neither top-down nor bottoms-up, it’s a middle-out approach, and it’s the only one that makes the gap any narrower.

このミドルアウトの考え方は、前に述べたようにユーザと開発者の距離を縮めることと同じ話なのだ

2007年3月 9日

ユーザ目線のBPM(10)

システムの構造とアーキテクチャ

ここまでで、SOAという言葉が何回か出てきたが、このService Oriented Architectureというのは一体なんなのか、どういう定義なのかと、言ってみたが、極端な話そんなことはどうでもよくて、要はビジネスサイドかつシステム技術サイドからの変更要求に早く、柔軟に対応できる仕組みを作りたいだけで、SOAを実行することが目的でもなんでもない。だから、SOAを実践した事例はこれですなんておかしな話なわけで、システムを作ったらそれがSOA的であったというのが正しいのであり、サービスをつないでシステムを作ればみんなSOAでいいのだ。

このあたりは、4~5年前に筆者がシステムの構造をどうしようとしていたかを説明するのがいいのかもしれない。

当時、メインフレームかオフコン上の基幹業務システムの外でいろいろなサブシステムや情報系システムが作られていた。それが、ほとんど連携しないで独立していた形でせいぜいFTPみたいなものでつながっていた。そこにやっとWebサービスのような技術あるいはEAIやBPMのようなツールが登場し、システム間の連携ができるようになったが、まだ多くの問題を抱え普及は大きくは進展しなかった。

ただ、システム間の連携という場合、まずはシステムを構造化することが大事であると考えた。「構造化する」とは、(1)全体を俯瞰したうえで、構成要素に分解し(2)それらの構成要素間の関係を分かりやすく整理し(3)統合化されたモデルを作ることであり、それぞれのレイヤで必要になる。

例えばEAでいうところの政策・業務体系では、業務をコア業務とサポート業務に分けさらにサプライチェンサポートとプロフェッショナルサービスや定型業務に整理してみることや、適用処理体系では、ERPを使うのか、手組みにするのか、外部サービスを利用するのかとか、もう少しシステム寄りで入力・出力系のアプリケーションをどう配置するかだとかになる。

こうして、アプロケーションやシステムコンポーネントを整理した後、重要になってくるのがシステムの骨組みをどうするか、そこの血流をどうするかである。

こうした、連携・協調に対する骨格としては、ハブ&スポーク型の構造が有効である。まあ、有名なあのFedExモデルだ。例えば、各アプリケーションで生成されたデータは一旦統合データベースに集められて、そこから各ユーザに配信されるというイメージだ。

このような、ハブになる仕掛けがいろいろある。いまデータの話をしたがデータの場合のハブはEAIやデータウエアハウスであり、帳票印刷・配布なんかも同じ考えができる。(その当時はこの統合プリントシステムがなかった) また、機能のハブがBPMであり、処理(プログラム)のハブはデータベースである。

こうしたハブ&スポーク型の構造が今でいうSOAにつながっていると思っている。FedExモデルも当初は単にモノを運ぶだけの仕組みであったが、最近は空港の近くに倉庫を持って物流・在庫管理を含めたサービスも提供するようになった。ということは、当初はハブ&スポーク型の構造でデータやその他の情報を行き来させるだけだったのが、サービスという形に変えて連携するSOA型に進化してきたのは、FedExと同じだと考えればわかりやすい。

ということで、最近ではハブが企業内だけにとどまらずインターネット全体に存在し、単純な構造から網の目のような複雑で柔らかい構造になってきている。ここで言ったようにこうした展開は、別にSOAを意識したものではなくある意味必然的にたどりつく道であるような気がする。繰り返すが、SOAを構築しましょうではないのです、柔軟で変化に強い仕組みが作りたくて、できたものがSOAだったということなのです。


2007年3月10日

ユーザ目線のBPM(11)

どうやって開発するか

さていよいよ、開発方法の話になります。開発というと忘れらない言葉があって、開発につきまとう2つのジレンマについてのことだ。その2つの大きなジレンマとは

1.アプリケーション仕様のほとんどが、結局、ユーザの恣意でしか決まらないこと

・・・仕様を決定付ける科学的、工学的なモデルが存在しない

2.情報システムと人間の境界が、元来不安定であること

・・・実業務の様々な例外をコンピュータ上に乗せるか否か

ということで、このジレンマを克服しないうちは、前に言ったようにユーザとITがお互いに嘆きあう状況はいっこうによくならない。ただ、ユーザ側からみれば、ある意味当たり前で、システム屋が困ろうが知ったこっちゃないのであって、目の前にあるビジネスをどう切り回すかだけを考える。だから、ITはそこで役に立って当然で、ITが足かせになるなんてもってのほかなのだ。

極論すると、社長が“こうしたい”と言ったらすぐに実現しなくてはならない。昔、松竹新喜劇の藤山寛美がリクエスト公演というのをやったけど、お客さんが望んだものをすぐに提供できるのがプロのシステム屋のすることでしょう。それを、“うちのお客はわがままなことばかりで全く困る”と言っているようではダメなのだ。確かに無茶なユーザがいて頭にくることは分かるが、そんなやつらを軽くさばくのがプロではないでしょうか。プロの定義は「ひとのせいにしないこと」だ。こうしたユーザの“ぶれ”とそれともうひとつ変化のスピードを前提とするなら、どうも従来型のアプローチでは対応が難しいように思える。ということは、システムの作り方を変えていかなくてはいけない。だからこそBPMが有効な手段である可能性を感じて探っているわけです。さて、BPMは”ビジネス機能、あるいはサービスをコンポーネントとして持って、それをBPMで組み合わせてプロセスを作り、それらプロセスの集合が業務アプリケーションとなる”と考えていきたい。その最初のコンポーネントを業務コンポーネントあるいは業務モデルと呼び、それをどんな方法で作るのか、あるいはどこかにすでにあるのかといったことが最初の議論となります。このあたりの試みはもちろんだいぶ前から行なわれていて、いろいろな角度からの検討があります。その結果としてERPやその他業務パッケージになったものもあり、また、データモデリングという切り口で見ているものもあります。そこで、少し最近の動きとして、「要求開発アライアンス」と「DOA+コンソーシアム」という2団体に注目してみていくことにします。両者のアプローチは違うが業務フローや業務モデルを描くという点では共通点があり、BPMが必要とする業務コンポーネントの生成についてどう取り組んでいったらよいか非常に参考になるし、場合によっては連携も考えられる。次回にこれらの団体の考えていることとその利用などについて述べていく。

2007年3月12日

ユーザ目線のBPM(12)

「要求開発アライアンス」と「DOA+コンソーシアム」

「要求開発アライアンス」というのは、2003年5月にビジネスモデル研究会としてスタートし、2005年3月に「要求開発アライアンス」として発足した団体。豆蔵の人たちが多く参加していますが全部で13人が発起人みたいになっています。当初、「要求開発宣言」としてまとめられたものが、このアライアンスの趣旨を表わしているので、長くなるが引用する。

・情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。

・情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。

・情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。

・ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。

・要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。

・「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。

これに基づき、モデリングのやり方やビジネスフローの標準化など要求開発の方法論が提示されている。

体系的でよくできていて、例えば「モデリングガイドライン」というのがあって、その中に「ビジネスフロー編」があるが、まずUMLアクティビティ図から業務の流れとシステムの関係を捉え、そのアクティビティの粒度の基準があって、それを調整して標準化するやり方が書いてあったりします。

ただこうした手法も有効かと思うが、トップダウンアプローチ的なところがあり、もう少し泥臭いやり方でいいのではないかと思ってしまう。

DOA+コンソーシアム」は、2003年12月に設立された。一体ここは何をめざすのかですが、この会の代表幹事であるデータ総研の椿正明さんの言葉を引用してみます。ちなみに、その他の代表幹事が東京国際大学の堀内一教授、株式会社エス・ディ・アイの佐藤正美さんという、DOAをかじったことがあるひとはびっくりするメンバーです。(3人が一同に会することも含めて)

システムの上流工程にモデルアプローチを適用するのが正解とされつつありますが、DOAなのか、それともUMLによるOOなのかについては、迷っておられる方が多いように見受けられます。さらにOOについては「人の数ほどいろいろなやり方がある」、また「DOAについてもいくつかのアプローチがある」ということで余計な混乱を招いているようです。 われわれは、「情報システムの製品は画面・帳票であり、これと直結したデータがシステムの基盤を作る」として、「まずはWHATとしてのデータを固め、次にHOWとしての処理を考えるDOAアプローチが正解なのではないか」と考えます。そして90年代、メインフレームからC/S、あるいはERPへのシフト に追われているうちに、「DOA技術の継承が中断され、危機的状況にあるのではないか」と心配しております。そこで「これを解消したい」との思いから、かつてのIRM研究会を思い出しながら、「DOA+コンソーシアム」を立ち上げることにいたしました。

狭く簡単に言うと、DOAとOOは対立するものではなくうまく棲み分けすることができるはずで、そのためにはUMLとの融合あるいはOOPとの接続が論点だとしている。

BPMではデータについてはあまり議論されていません。業務の構造は、プロセスモデルとデータモデルで表現されるものですから、しっかりしたデータベースの構築は非常に重要です。そのためのアプローチはDOAが一番です。ですから、BPMとデータモデルはうまく連携する必要があります。従って、DOAでデータモデリングすることは必須になると考えます。

詳しくは次回に。

2007年3月13日

ユーザ目線のBPM(13)

DOAによるデータモデリング

DOA+の手法についてはいくつかあって、代表的なのが「T字形ER手法」、「THモデル手法(PLAN-DB)」、Xprime(Xupper手法)、「三要素分析法(渡辺法)」などである。それぞれ特徴があるが、THモデル手法を開発したデータ総研の椿さんの考え方を中心に書いてみる。

前にも言ったように、業務モデルは「プロセスモデル」と「データモデル」から成り立っていますが、この業務モデルは実装独立であることが重要です。例えば、受注という業務を考えたとき、顧客、商品、数量、納期、金額などのデータが扱われますが、これはいつの時代でも変わらないもので、変わるのは実現手段です。従って、業務アプリケーションソフトウエアは「業務モデル」を実装手段を用いて実現したものとなります。ここが今まで一緒くたになっていたと思われる。

さて、業務モデルの構成要素を椿さんは次のように定義しています。

クライアント側の要素  : 「人」と「IO」

サーバー側の要素    : データベース、エンティティ、データ項目


これらの要素をフロー図やIOイラスト、概念DB構造図、データ定義書などに表現するわけです。そして、こんなことも言っています。

われわれの夢は、今は価値がないとされる業務モデルのコンテンツが流通し、市場価値を持つようになることです。ある単位の業務モデルリポジトリのコンテンツをライブラリとして貯え、これを適宜選択・組合わせて、自社に合ったデータモデルを構築することができれば、「パッケージに身体を合わせろ」と言った妥協を大幅になくせるものと考えます。これをアメリカより、1年でも2年でも早く実現するのです。そうすれば90年代に付けられた差を一気に逆転する可能性すらあるように思うのです。

そうですよね、椿さんはもう70歳を越えて益々元気なひとで、そのアグレッシッブさには頭が下がりますが、ぜひ夢を実現していきましょう。

つぎにDOAの条件として、「データ先行・リソース先行・概念先行」ということになります。データをプロセス/処理に先行して考え、イベントデータ(受注・出荷・請求など)より先にリソースデータ(社員・顧客・商品など)を固め、物理データベースより概念データベースを先行するという意味です。 こうして、DOAで業務アプリケーションの開発をやってみると、データ構造からみてつぎの6種類に分類できると言っている。

A.建設:見積-受注-建設計画-建設-検収

B.生産財製造業:受注-生産計画-生産-出荷

C.消費財製造業:販売計画-生産計画-生産-受注-引当-出荷

D.卸業:販売計画-仕入-受注-出荷

E.小売業:販売計画-手配-販売

F.サービス:契約-設定(工事/担保)-サービス-検収


また、企業はこのように基幹系業務は、A-Fの6種類に分類できるが、企業にはこのほかに、次のようなリソース(経営資源)整備軸とも言うべき6種類の業務アプリケーションがあるとのこと。これは、別な言い方をすれば、コア業務システムを支えるサポートシステムとも言える。

1.人材調達・育成(人事)

2.市場開発・保守(CRM)

3.設備建設・保守

4.商品開発・改良(PDM・PLM)

5.資金調達・利殖(財務)

6.情報システム開発・保守

まあ、ここではDOAがメインテーマではないので、かなりざっくりとポイントだけ書いてみましたが、何となくBPMとDOAの関係がわかったでしょうか。

例えば、上記業務アプリケーションに必要なデータモデルがあるでしょうから(なかったら、この手法で開発する)、それを使ってBPMでプロセスモデルを生成するというスタイルは有効のような気がします。というより、データモデリングとうまく連動しないといけないのです。

この他、これから注目したいのは、羽生章洋さんのABD(Activity Based Datamodel)や仕事の流れを表現するマジカあたりで、気になるところです。

2007年3月14日

ユーザ目線のBPM(14)

業務プロセスモデリングの進め方

ここでは、業務プロセスのモデル化を行い、できあがったプロセスからある単位(粒度)で切り出してコンポーネント化する作業のとっかかりのところを議論することにする。

まず、要件を定義していくとき、トップダウンアプローチなのかボトムアップアプローチなのか、AsIs先行かToBe先行かという問題があります。ここでいうトップダウンアプローチとうのは、経営管理あるいは事業運営上必要となる要件、いわゆるビジネスモデル的なハイレベル要件から見るもので、ボトムアップアプローチというのは、逆に業務フローをまわすための要件、いわゆるオペレーショナルなローレベル要件からみるものであるが、当然両者とも必要なアプローチであるが、筆者は最初はローレベル要件から入って、そこを固めてからトップダウン的にこだわり要件を付加していくやり方が現実的であると考える。

同じように、AsIsかToBeかの議論もAsIsから入ってTobeへ持っていくほうがこれまた現実的だと考える。

理想的には、経営戦略や事業戦略からあるべき姿を描くほうが、BPR的だし、新しいシステムによって会社を変えるんだという意気込みのある企業にはいい方法かもしれませんが、非常に難しいアプローチのように思えます。コンサルやベンダーはどちらかというとこのやり方を推奨してきます。

筆者も以前はそのやり方がベターと考えていたが、これだと、一旦既存のシステムや仕事のやり方を忘れてゼロベースで考えてください、そしてこうすべきだという姿を描いてくださいとなるわけですが、そう言われても普通の人はとても難しく、どうしても今もこうだからとか手持ちのリソースでは無理だとか思ってしまう。結局、現状ベースから抜け出せないことになる。それならいっそ最初からボトムアップでAsIsから入ればいいのではないかと考えるのです。

モデリングの進め方の概略としては、

1.現状の業務プロセス(AsIsモデル)を抽出します。

2.その業務プロセスをプロセス・アクティビティ・タスクなどに分類・整理して可視化します。

3.可視化された現状業務からプロセスと業務機能を分析・評価します。

4.プロセス・機能を共通化・標準化・一貫化したり、重複を排除したりプロセスを適正化します

5.事業要件などから追加・修正を行いTobeモデルを作成します

このとき、ただプロセスと機能のマトリックス表を埋めるだけになってしまうと、単なる現状追認業務モデルになってしまうので、どうやって適正モデルにもっていくかが重要なポイントとなる。そこは人の頭の中で考えてよ風の方法論があったりして困ってしまうことがある。だから、そこを属人性を排した論理的なメソッドが必要となるのだ。だれがやってもだいたい同じ結果になるようなルールやガイダンスが用意されているかとなる。

いまここで、適正モデルと言ったが、ほんとうは最適モデルと言いたいのだが、2つの点で最適モデルができるのだろうかと疑問になる。ひとつは、真の最適モデルが作れるのだろうかという問題で、何もかも満足できる成果物となりえないのでないかということです。

もうひとつは、よしんば最適モデルができたとしてもその寿命はどれだけあるのだという問題で、いまの世の中ではすぐに陳腐化してリニューアルしなくてはならなくなる。従って、苦労して最適化するより、その時点で最適に近いと思われるところでどんどん進めていって、絶えずアップデートしていくようなやり方ができないかということである。ですから、最適モデルというより、「適正モデル(Normalized Model)」としたほうが何となくマッチしていると思うのですがいかがでしょうか。

2007年3月15日

ユーザ目線のBPM(15)

業務プロセスの適正化

前回、概略のモデリングついて述べましたが、今回はそれをもう少し詳細にみていくことにします。

まず、AsIs先行ですから、最初に現状業務プロセスの抽出を行いますが、これは一般的にやられているように業務フロー図(アクティビティ図という場合もあり)に書き出すことになります。既存システムがある場合はその画面や帳票から抜き出していきます。

また、業務としてのプロセスを捕捉するわけですから、システムで行っているものだけではなく、手作業や外部に委託している作業なども書きだします。業務フロー図は2次元ですから、2軸に何を記述するかがありますが、部署・役割―工程・プロセスというのが普通です。

こうして、AsIsベースの業務プロセスを抽出したら、プロセスと業務機能のマトリックス表(Excel)を作成する。対象プロセスは、プロセス・サブプロセス・アクティビティに階層化される。例えば、受注~売上計上―受注-注文受付というイメージです。

このとき、プロセスは始点と終点が明確になって完結していることが重要なポイントです。そのアクティビティレベルで業務手順、前後のつながり、参照情報、作業手段、帳票、担当者などを記入する。これにより、現状のプロセスと機能機能(アクティビティ)が整理されます。ここでのチェックポイントは、

1.業務プロセスと業務機能が全部抽出されていること

・・・抜けているプロセスや機能がないか

2.業務プロセスが自己完結していること

・・・業務がどこで終わっているか不明だったりしないようにする

さて、ここからToBeへ展開していくわけだが、具体的には、まずつぎのような視点で見直ししていく。

1.業務プロセスとデータが途切れず流れているか(一貫化のチェック)

2.業務プロセスが複雑で分かりにくくなっていないか(シンプル化のチェック)

3.業務機能で似て非なるものがないか(共通化のチェック)

4.同じ業務処理なのに部署によって違っていないか(内なる標準化のチェック)

5.業務機能で例外処理がないか、へんなこだわりはないか(外なる標準化のチェック)

6.電子化やシステムに置き換えられることはできないか(IT化のチェック)

とにかく”シンプルな”業務プロセスにすることが最も重要である。ムダのない単純な構造は美しいものなのです。

上記視点で業務プロセスと機能を見直していく。具体的には、二重入力・起票の有無、迂回路有無、重複作業、分岐処理などいくつかのチェック項目を設け、それを上述の表に追記していく。同時に共通化あるいは標準化できる業務機能を洗い出して、その機能を汎化や集約を行ないながら定義していく。

こうして、共通化、標準化された業務機能からなるシンプルで一貫化されたプロセスができあがる。この一連の進め方を業務プロセスの適正化と呼ぶ。ここをある程度自動化できないかというのが筆者の願いなのです。ツールが適正モデルに誘導してくれるイメージです。BPMSにこうした機能が具備されることを期待している。

さて、ここでとりあえず“きれいな”プロセスとなるが、あくまでボトムアップ的アプローチであるため、ハイレベルな要件があれば、このプロセスに付加して価値を高め、差別化を図っていくトップダウン的作業がある。“魅力的なプロセス”になるかどうかはここにかかってくる。ただし、ここはもちろん自動的にはいかないのでしっかり議論し、ベンチマーキングもしながら知恵を出すことになる。

2007年3月16日

ユーザ目線のBPM(16)

コンポーネント化

プロセスができたら、そこから機能(プロセスまで含む場合もある)をカプセル化して、コンポーネントを作成していく。まず、コンポーネントの分類と粒度ということから考えていこう。

業務プロセスは、業務サービス―業務コンポーネント―システム機能コンポーネントから成り立っていると考える。例えば、「販売管理」で「受注」~「代金回収」までのプロセスを考えると、そこには「出荷」という業務サービス(この単位でコンポーネントとしてもかまわない)があり、そのなかの「出荷指示」というアクティビティが業務コンポーネントになる。

一方、認証だとか帳票やコード変換といったシステム的な機能については、システム機能コンポーネントとして括り、共通部品的な使い方となる。もう少し、例示的言うと、

・業務サービス      :見積り、受注、発注、与信、クレーム処理、出金伝票承認・・・
・業務コンポーネント   :受注受付、在庫引当、検収、見積査定、出荷指示・・・
・システムコンポーネント:カレンダー管理、データ集配信、ロール管理、メール・・・

これらの粒度でコンポーネント化をしていきます。コンポーネント化は、MVC(model/view/control)モデルをベースにして行ないます。また、当然データベースがきちんと構築されているという前提です。ただし粒度については、これでは大雑把すぎますので、作業者がひとりで行える単位にするとか後続機能に後処理を依存させない単位にするだとかの基準は設ける必要があります。

ちなみに、大和総研の池田大造氏は、コンポーネント化の指針で、分割基準として、「最小構成単位」と「機能的な完結」,「コンポーネント構造」をあげていて、その中の「最小構成単位」でつぎのように言っています。

複数のアプリケーションを集めたコンポーネントの最小構成単位は,ビジネスで扱う人や物など「もの」として定義された対象物(エンティティ)の生 成から消滅までにしている。例えば債権についてのコンポーネントは,債権の発生から消滅に関する更新要求や参照要求への対応,ビジネスロジック(債権充 当,充当修正,滞納判定,滞納情報作成,滞納解消情報作成,回収代行債権返戻情報作成など),コンポーネント外部とのインタフェースを制御するデータ変換 部分を対象とする。コンポーネントは,情報として管理するものの最小単位ともいえる。

また、何でもかんでもコンポーネント化すればいいというものではなく、なかにはコンポーネント化に向かない機能もあるので、そういうものは無理してコンポーネントにしたところで再利用もされないわけなのであきらめます。例えば、スタッフの不定形作業なんていうのは難しいのではないでしょうか。 こうして作られたコンポーネントをライブラリーに格納して使い回していきます。

さて、このコンポーネントすなわち業務モデルは標準業務モデルであるのかという問題がある。前にも書いたが、標準化では、内なる標準化と外なる標準化という表現をした。内なる標準化というのはいわば社内標準であって、支店や営業所でまちまちであった処理慣習などを標準のものにすることである。一方外なる標準というのは、業界標準であるのかとかグローバルな目でみたとき固有性が排除されているのかといったことになる。

おそらく、業務コンポーネントのレベルでは、自社固有の部分は少なく、業務サービスのレベルで固有性が現れるのではないかと筆者は考える。従って、業界あるいは一般的に業務コンポーネントを共通利用するのは可能であるように思える。ですから、業務サービスはこの業務コンポーネントの集合ですから、その組み合わせで“クセ”が出ると考えられないか。このことは、逆に差別化する源泉でもあるわけで、他社と比べて違った業務サービスを持っていることが事業上で有利になるとも言える。「組合わせの妙」ということだ。

さて、業務サービスという言葉で言ったようにこのレベルでひとかたまりにして大きな粒度のコンポーネントにしてもかまわない。だから、狭義のERPや業務パッケージもコンポーネントと考えてもいいと思う。その場合は、カスタマイズやアドオンがほとんどないという前提での話しだが。

さらに、そうしたサービスを自分たちで作るのではなく外部から持ってくることも可能だ。例えば、与信管理のサービスを外部の信用調査会社のサービスを利用するとか、最近では福利厚生関連の多くは外部サービス化している。

次回にこうしてできたコンポーネントあるいは外部サービスを使ってシステム開発する「コンポーネント開発」について論ずる。

2007年3月17日

ユーザ目線のBPM(17)

ビジネスコンポーネント指向開発

コンポーネント活用の開発法には、「コンポーネントベース開発」とか「コンポーネント指向開発」などと呼ばれているものがある。しかし、いずれもソフトウエアのコンポーネントという考えが強く、ビジネスの視点が弱いので、ここではあえて「ビジネスコンポーネント指向開発」とする。

さて、コンポーネントを使って開発しようというのは、まずは早く開発できること、すなわち開発効率があがること、変更要求に素早く対応できることなのだが、これだけだと、まだ前に言った「開発の2つのジレンマ」の解決にならない。特に仕様がなかなか固まらないことへの対策は弱い。それでは、なぜユーザは仕様を決めないのだろうか、決められないのだろうか。

おそらく、一番大きな「理由はユーザが“なかなかその気にならない”ということではないだろうか。そうですよね、どんなプロジェクトでも尻に火が着かないとまじめに考えないものなんです。いくら、開発側が早く仕様を決めてくれと言っても、いま忙しいからだとか、自分じゃ分からないので現場の人に聞いてみるからちょっと待ってくれだとか言っていっこうにフィックスできないことが多い。また、逆にあれやこれや思いつくものななんでもいいから仕様に入れておけということになる。これをどうにかしたいのだ。

ということは、ユーザに早く本気モードにさせるのはどうしたらいいのだろうか。筆者は、とりあえず動くものをその場ですぐに見せることだと思う。見たものがすぐに稼動できてしまうのだということがわかると真剣に向き合ってくれるはずだ。ユーザの心理としては、紙に書いたものを見せられてもよくわからないし、周りのメンバーにも説明できない、実際の画面がどう動くのかとかをチェックしながら決めたいと思っている。それに、いくつかのケースを動かしてみて比較して決めたいのですぐにそれができるようにしてほしいのだ。Ismael GhalimiがBPM2.0で必要な機能としてOne Click Deployを揚げていたのはこういうことではないかと思う。

コンポーネントベース開発の概略手順はつぎのようになる。

1.対象業務プロセスの特定

2.プロセスと機能のマトリックス表の作成

3.コンポーネントライブラリーから適用可能ものを選ぶ

4.ライブラリーにないものは書き出す

5.BPMのモデラーを使ってフローを書くと同時に適正化を行なう

6.必要に応じてハイレベル要件を埋め込む

7.ライブラリーにないものは極力コンポーネント化

8.すぐに実装してユーザと摺り合せ、戻って修正・テストを繰り返す

9.システム本番稼動

この開発の特徴は、キーワードでいうと、モデル駆動型、イテレーション開発、テスト重視というところでしょうか。また、大事なポイントは、ユーザに見せてから稼動までを最短でやるために、実際に動くものを見せて、その場で修正してやっていくようなことでないといけない。他所からそんなことはシステムを知らないやつが勝手に言っていることだという声が聞こえてきそうだが、無理を承知で知恵をだすべきだと思う。

このプロセスで難しいのはモデリングと実装のギャップをどう埋めていくかだが、そこはいわゆるSE(最近はITアーキテクトとも言う)の登場でしょう。すなわち、ビジネスプロセスデザイナーが業務モデルをデザインし、プログラマーがコンポーネントをつくり、システムエンジニアそれを実装するという役割になる。それぞれの間でのコラボレーションや「摺り合せ」が開発プロジェクトを成功に導くのだ。

この開発形態は、ウォーターフォール型では難しく、アジャイル開発、手法としてはXPに近い形になると思うが、ユーザの人にとっては、むしろ、「セル生産方式」といった方がわかりやすいのではないだろうか。あのキャノンの生産方式で多能化された少数の人で最初から最後まで組み立ててしまうやりかたで、「ビジネスコンポーネント指向開発」も「セル生産方式」のように、数人で組み上げるイメージなのではないだろうか。

この開発方法は、(株)日立製作所 ソフトウエア事業部の桐越信一氏が提示している「コンポーネントベースモデリング」が非常によく整理されて参考になる。ただ、データモデルにあまり言及していないことと開発はフェイズドアプローチを言っているのがちょっと気になる。

また、「コンポーネントベース開発」ということで言えば、コンポーネントスクエアという会社ができていて、CBDスクエアというコミュニティを運営して、まさに「コンポーネントベース開発」について議論している。ただし、ここでは、参加がSIer中心のようで、ビジネスというより、どうしても開発側のシステム寄り視点になっている。だから、いい業務プロセスを作ろうというのではなく、再利用性が高いコンポーネントをどうやって作ったらいいのかという開発効率重視の考えが強いように思える。これは、再三言いますが、このコミュニティだけの話ではなく世の中全般に言えることのようです。

2007年3月19日

ユーザ目線のBPM(18)

コンポーネントの粒度

ここまででは、コンポーネントとして、業務サービスという言い方をした小さな単位の業務プロセス、例えば「受注」というようなものもコンポーネントとみなすと、こうした大きな括りの業務サービスコンポーネントがあって、その下に「受注受付」のようなアクティビティあるいはタスク主体の業務コンポーネントがあり、それを動かす共通基盤的な仕組みとしてのシステム機能コンポーネントがあると言ってきた。それでは、それぞれのコンポーネントの粒度をどう考えていったらよいのでしょう。

システム機能コンポーネントについては比較的考えやすいと思うので、ここでは、業務コンポーネントについて考えてみる。

まず、抽象的な言い方だと、ビジネスの環境や組織が変わっても、それ自体変わらない部分をコンポーネントの単位とすることなのだが、例えば、会計処理なんかはそのプロセスはそう大きくは変わらない(法改正、制度変更はあるが)から、業務パッケージそのものがコンポーネントと言えないこともない。こんな場合は、それをひとつのサービスとして括ってもかまわない。

最近Webサービスという形でネット上にもこうしたサービスが登場してきている。有名なSalesforce.comのオンデマンドサービスはまさにまるごと外部のサービスとして利用できる。だから、他社と差別化する必要のない機能は、できるだけ個別企業ごとに作るのではなく、外部のサービス利用という形態が望ましい。

こういうことができるようになったとというのがSOAのもたらした効果なのだ。企業は、システムを“作る”、“買う”(パッケージを買うという意味)、“借りる”のバランスをうまくとりながら構造化を図ることが大事である。

さて、もう少し具体的に見ていくと、一番問題となるのは業務コンポーネントの粒度をどうするかだ。この中には、単なるワンアクションのようなものから、ワークフローを含んだ処理までが想定されると考えられる。「生産量登録」みたいなものから「見積依頼」というようなワークフロー的なコンポーネントのことである。

例えばこの「見積依頼」という業務処理を考えてみよう。工事の見積を行なうと仮定するとこの処理は、「仕様書作成」→「仕様書承認」→「見積依頼書作成」→「見積依頼受付」→「見積依頼」のように流れる。このとき、「仕様書作成」のレベルを一つの業務コンポーネントとして、それらをBPMでつないでプロセスを作っていくというのもありですが、少し細かすぎるような感じがする。

そこで、BPMとWorkFlowについてだが、厳密な定義があるのかないのか知らないが、似ているように思うし、一緒のように言う人もいる。よくわからないというのが正直なところで別にそんなことを考えなくてもいいと思う。むしろ、WorkFlowって一体なんなのだろうかと見るほうが大切で、仕事というのは、ひとからひとへシークェンシャルに流れていくものであるという前提でWorkFlowという概念が成り立っている。

確かに、稟議決済なんて仕事が流れていく典型であるけど、大部分はその前提を崩して考えてもいいような気がする。すなわち仕事が流れるのではなく、“状態が遷移する”と考えるべきだということです。だから、ワークフローというのは、フロー制御とステータス制御の2通りあると捉える。

以前、.NETのフレームワーク上で動くコンポーネントを開発し、それを使ったアプリケーションを構築することを試行したことがあったが、そのとき業務というのは、書類をイメージした「データコンポーネント」が転記されて受け渡されることだと規定したことがあるが、これと似ている。

また最近、こうしたことを気づかせてくれたのは、あるCMSツールです。それは、Ploneといって、オープンソースのアプリケーションサーバーであるZopeとそのフレームワーク上に構築されたコンテンツ管理システムなのですが、そのなかにワークフローの機能があるというのです。で、よく見てみると、“オブジェクトの状態とユーザロール”を中心に構築されているのです。簡単に言えば、共通の場で情報を共有してそのステータスをコントロールすることで仕事ができると言っているのです。

このあたりはまた後述しますが、粒度の話に戻ると、ここにヒントがあって、ここで言うオブジェクト単位で粒度を設定すればいいのではないかということです。では、そのオブジェクトとは何だろう。筆者は上述したように、それは「書類」ではないかと考えている。すなわち、仕事の単位は、書類(必ずしも紙でなくてもいい)を作成してそれに追記・転記して完結するということではないかと考え、それをコンポーネントと捉えたらどうだろうか。このように考えてもいい業務処理はわりと多いと思われる。

従って、従来WorkFlowといっていた部分は、StatusControlとし、対象となるオブジェクトを書類(広義)とし、その単位でコンポーネント化する。コンポーネントは例えば、PloneのようなCMS(もちろん他のWebアプリケーションでかまいません)みたいなものでできて、それらのコンポーネントをBPMを使ってプロセスにしていくというのがざっとしたイメージになります。

ミクロなサブワークフローは軽量Webアプリで、マクロのメインワークフローはBPMという構成です。言ってみれば幹線道路はBPMで作るが支線や私道は軽量フレームワークでさくっと作ってしまい、ジャンクションは標準の取り決めに従ってつなぐという感じになりますがいかがでしょうか。全部がこれでできるとは思っていませんが、挑戦してみる価値はあるように思えます。


2007年3月20日

ユーザ目線のBPM(19)

Web2.0のインパクト

前回、オープンソースのCMSの話がでたが、いま話題のWeb2.0とBPMはどういうことになるのだろうか。ここは、前に言ったBPM2.0という意味ではなく、Web2.0の思想やサービスモデル、技術についてのことだ。

Web2.0というとつい、Google、Amazon、Yahooといった企業あるいはWikipedia、SNS、ブログ、Youtubeといったサービスに注目するが、実は重要なことは、そこにある思想と支える技術の両面をきちんと理解することではないでしょうか。
有名なO’Reillyが作成した下記「Web2.0ミームマップ」を見るとWeb2.0の概念がだいたいわかる。

meme_map_small.gif

このなかから、BPMあるいは企業情報システムと関連する記述を見てみよう。
まずは、情報のハンドリングについては、「情報の自己コントロール」「集合知の利用」「参加のアーキテクチャ」がある。すなわち、Wikipediaに代表されるようにみんなが知恵を出し合ってできたものが一番いいものができるということ、さらにSNS、ブログ、Amazonレビューのような皆が情報の発信者になれるということで、こうしたユーザを信頼する楽天的民主主義の色合いが強くでているのがわかる。

システムのつくりみたいな領域では、「プラットフォームとしてのウェブ」、「パッケージソフトウエアではなくサービス」「永久にベータ版」、「利用者が増えるほど改善されるソフトウエア」、「モジュール化とゆるやかな統合(コンポーネントとしてのウェブ)」といったところになるが、これまで議論してきたことに大いに関連していると思いませんか。Webの世界と企業情報システムサイドとがだんだん近づいてくるように思えます。

ただし、ここで重要なことはWeb2.0の世界というのは、既成の概念を打ち破るパラダイムシフトのことですから、企業にとっても情報システムだけの話ではなく、企業体質、組織、仕事のやり方などが変革されなければ受け入れられない思想なのです。次世代の企業をめざすのなら、Web2.0的体質にならなくてはいけないし、脱皮できた企業が生き残っていくような気がする。

Web2.0によってもたらされた変化はいったいなんなのだろうか。

企業にインパクトを与えるものとしては、まず参加型のアーキテクチャがあげられる。ブログやソーシャルネットワークに代表されるように誰でも情報発信できるようになったことが大きい。これまで情報交換はせいぜいメール(メーリングリスト)ぐらいでしたが、これからは社内ブログのようなものも出てくるでしょうし、社外に対しても積極的に情報発信していかないといけなくなるわけで、これは、結果的に情報共有、情報公開ということが非常に重要な要素となり、平気で「不都合な真実」を隠蔽するような企業は生き残れなくなる。

この参加型のアーキテクチャというのは、従来の階層型の組織では受け入れられない考え方で、組織をフラット化してこそ生きてくる。実は、前回ステータス管理という仕事のやり方について書いたが、これがまさに参加型のワークフローなのだ。

従来のように階層化された組織を順番に仕事を流していくやり方では、そのフローのなかで業務処理の状況がどうなっているのかわからないまま、自分のところに“さあ、承認お願いします”と来ても困ってしまう。最初から利害関係者が参加し、そこで意見交換しながら仕事を進めていけば、自ずと意思決定も早くなるのではないでしょうか。

また、オープンソースプログラムのようにネット上にソースを公開し、そこに誰でもアクセスでき、知恵を出し合いながら作り上げる。こうした、知的生産活動はいままでのように個人で仕事を抱え込み、また抱え込むことで自分の存在価値を確認しているようなやりかたと違い、「永久にベータ版」として早めに衆知にさらせば、知的生産活動で生み出される情報の質はかなり向上する。要するに、社内の情報を握っているだけで部長になるようなことがなくなっていくということだ。

いまや、こうした情報リテラシーをもった若者がどんどん会社に入ってきている時代だ。会社自体も会社2.0に変貌していかないと、入社したはいいが3年で辞めていかれてしまうのではないでしょうか。

さらに、これまで自分のデスクトップ上にあったデータをネットワーク側に蓄積するようになり、それを基にネットワーク側から様々なサービスが提供されるようになった。それとソフトウエアが無料で使え、インターフェースも標準化され、簡単にHack、Mashupできてしまうチープ革命といわれることがあります。

しかしながら、この恩恵を受けるには自己責任ということを覚悟しなくてはいけない。それができる企業は自らの手で自らの責任でシステムを構築していくことを選択すべきであろう。それがいやなら、相変わらずベンダーの言うとおりに、20%の機能しか使えないソフトウエアを買い続けることだ。

ただし、無条件に無償のオープンソースを使うことを薦めているわけではありません。そこには、今言った自己責任ということとともに、技術に対する目利きと使いこなす技術力がいるため、やみくもにとびつくことはしないほうがいいと思います。自社のリソースを頭に入れて、そのメリット、デメリットをきちんと見極めることが大事です。

今回は、Web2.0の思想と企業の体質、組織などについて述べたが、次回はもう少し技術的な側面について考えてみる。

2007年3月22日

ユーザ目線のBPM(21)

だれがどこでやるのだ

今まで、Why、What、Howについてみてきましたが、最後に残りのWho、Where、Whenを考えておかないと紙の上の議論となってしまいます。最初の頃にも言いましたが、動いてなんぼ、役に立ってなんぼの世界であるので、具体的にどういう体制で、どういう組織で、どこに適用し、いつやるのだということを提示することも重要であると思う。

体制のことで言えば、業務プロセスのデザインをビジネスプロセスデザイナー、業務プロセスの実装をITアーキテクト(従来のSEの進化形)、プログラミングをスーパープログラマーというのが理想的である。このチームで「セル生産方式」のように一気に作り上げることが望ましい。たとえが悪いが、「必殺仕事人」「黄金の7人」みたいなものだ。ここで作られたコアシステムをベースにカスタマイズしたり、運用したりするのは、一般のひとがやっていくという役割分担になる。

ここで、軽量プログラミング言語を操る技術者をどう巻き込んでいくがポイントだ。たとえば、IPAの未踏ソフトウエアの卒業生を引き込むとか工夫する必要がある。

また、このビジネスプロセスデザイナーという役割をどうするか。前に、企業IS部門や情報子会社について、彼らはどちらかというとベンダー寄りであると書いた。ここでは、期待を込めて、この役回りを企業IS部門あるいは情報子会社が負うことを提案する。

従って、従来に比べ、さらに業務側にシフトしたスタンスとする。これは前にも言ったように、別にユーザと同じレベルで業務を知る必要はなくて、BPMという道具を使い、手持ちのコンポーネントを見せて、必要とする業務プロセスを引き出す能力をもつことでかまわないのだ。

情報子会社が本質的に抱える課題である自立化を実現するヒントになると考える。これは本題ではないのでこれ以上は言及しない。

ただし、こうした開発部隊をどう組織化するかは難しい課題である。次に述べる地方の中小企業に導入する場合など、必ずしも情報子会社でやれるとは限らないケースもあると思われる。全国規模のITベンダーの力を借りることも必要になるかもしれない。

さて、実際にここで論じた方法論や仕組みをどこにどうやって適用するのがいいのだろうか。その答えとして、中小企業への適用を行い、地域ごとのビジネスサポートセンター設置を構想する。なぜそう考えるに至った理由について、昨年「日経ソリューションビジネス」に掲載された記事が参考になるで引用する。この記事は「中堅・中小企業の市場に対する「これまでの常識」と7つの「新常識」」と題したものでベンダーに向けて発信されているが、状況を的確に捉えているのであえてそのまま載せる。

これまでの常識

①中堅・中小企業もまずは経営戦略を立案した上でシステム化すべき

②日本版SOX法は、上場企業などに適用され、中堅・中小企業には関係ない

③中堅・中小企業でも基幹業務システムを提案することが最も重要

④中堅・中小企業はシステムを導入しても単価が安く、あまり儲からない

⑤中堅・中小企業は、料金設定を安くしなくてはシステムを導入してくれない

⑥最新システムを入れる中堅・中小企業は、IT化にも理解があり進めやすい

⑦社内にIT部門をもたない中堅・中小企業が多いため、導入作業が面倒

これからの常識

①まずは効果を出しやすい部分からシステム化して、ITの重要性を示す

②たとえ適用されなくても、上場企業と取引するとき今後、内部統制が必須に

③業務コスト削減の基幹業務システムより、売上に直結するWebシステムの提案を

④システムより、付随する業務サービスに価値を認め対価を支払ってくれる

⑤短期間にシステムを開発してくれるなら、高い料金設定でも納得してくれる

⑥むしろ遅れている中堅・中小企業の方がスムーズにシステム化が進む

⑦中堅・中小企業の社員は、費用が安くなるなら積極的に導入作業を助けてくれる

これを見たらおわかりのように、「ユーザ目線のBPM」は、中堅・中小企業をターゲットにするのが適していると思いませんか。

また、社内にIT部門をもたない中堅・中小企業が多く、運用を自社で行なうのが困難であり、コア業務に集中するために運用は外部にまかせたいと考えている。従って、センター化してASPサービスとして機能させることが望ましい。

筆者は、全国の信用金庫単位でこのセンター(ビジネスサポートセンターと呼ぶ)を構築したらどうかと提案している。それぞれの信用金庫には多くの中堅・中小企業がぶらさがっています。その企業群が共同で利用できるビジネスシステムを提供することをめざします。全国に292の信用金庫がありますが、どこかひとつを選んでそこで実装し、モデル化して全国水平展開するというイメージでいかがでしょうか。

いつやるかは、全体スキームの確立状況をみて決めていくことになります。

日本の強さは中堅・中小企業の力によるところが大きいと考えられます。さらにそこを強化して行こうではありませんか。


2007年3月23日

ユーザ目線のBPM(22)

最後に

ここまでの議論を整理してまとめると次のようになる。

・役に立たない正しいシステムを作るのはもうやめよう
・役に立つものができるなら、従来の作り方を変えようじゃないか
・それにはBPMを使ってコンポーネントを組み立てる作り方が有効なようだ
・BPMは開発と監視の道具であるとし、使い勝手を重視しよう
・BPMはSOAの基盤の上に構築するのが構造的によさそうだ
・コンポーネントは、Web2.0的技術あるいはサービスでさくさく作ってしまいたい
・早く安く作る事が重要でしかも変更や手戻りは当たり前と考えよう
・コア開発は、ビジネスプロセスデザイナーとITアーキテクトとスーパープログラマーのチームで迅速に、カスタマイズ適用と運用は“一般”チームで確実に
・小さく生んで大きく育てる思想で、非基幹系、中小企業向けから始めよう

この議論の表題を「ユーザ目線のBPM」としたが、これは筆者がエンドユーザであった時代、そしてIS部門、情報子会社でシステム構築を行なってきたときの経験から、どうもこれまでのシステム作りがメーカ、ベンダー、SIerの目線で行なわれてきたように感じられたので、あえてそのようなタイトルにした。
目線ということで言えば、最近「下流志向」という本を書いた内田樹氏がこんなことを言っている。

「目線」というのは「そこから何が見えるか」ではなく、むしろ「そこからは何が見えないか」によって特徴づけられる。例えば、本邦のテレビのニュース番組のほとんどは「おばさん目線」である。だから、私たちがワイドショーやニュースから知れることができるのは「日本のおばさんは何を知っているか」ではなく主に「日本のおばさんは何を知らないか」である。これはそれなりに有益な情報である。

この傳でいけば、「ユーザ目線」というのは、「システムについてユーザからは何が見えないか」、「日本のエンドユーザの人たちは何を知らないか」ということになる。この議論で“それなりに有益な情報”を提供できたのであろうか。おわり。

2007年4月10日

ビジネスコンポーネント指向開発(1)

はじめに

「ユーザ目線のBPM」で実際に動くものをつくらないといけないと言い、その形としてオープンCMS(oss-CMS)によるコンポーネントをBPMでプロセス化することを提案した。そこでこの「ビジネスコンポーネント指向開発」についてもう少し具体的に考えていこうと思います。

その前に、おさらいの意味でもう一度「ユーザ目線のBPM」のなかでなぜ「ビジネスコンポーネント指向開発」を提唱したかを整理してみる。

BPMはまだきちんと定義されているわけではなく、共通認識がないように思われる。従って、ひとによって様々なアプローチがある。
大きくは次のようなアプローチがあるように思える。
①企業の業務を分類・定義し、モデル化・体系化を行なう。
②企業の業務をフロー図などに書き出し可視化する。
③業務コンポーネントを組み合わせてBPMでプロセスをつくりあげる。
④BPMを使ってSOAの仕組みを構築する。

さて、BPMを考えるうえで重要な視点はいったいなんなのだろうか。それは、BPMの最終ゴールはどこにあるだろうかということに他ならない。そして最も適した答えは、「事業の役に立つ業務プロセスをつくること」ではないだろうか。

経営ではなく、事務ではなく事業のためであり、その事業の足を引っ張ることはもってのほかで、事業が円滑に運営するための本当に役に立つ仕組みでなくてはいけない。

そう考えると、上記のアプローチでは物足りない。事業の役に立つためにさらにどこまでやらなくてはならないかを掘り下げる必要がある。従って、つぎのようなところまでやってこそ初めてBPMらしくなる。

①では、そこで作られた業務モデルをテンプレート化し、ベストプラクティスとして利用する。
②のフロー書き出したら、さらにその業務フローを標準化・最適化する。
③は、事業からの変更要求に柔軟かつ迅速に対応できるようにする。
④は、事業部門というよりシステム部門の役に立つことかもしれない。

で、今回提唱している「ビジネスコンポーネント指向開発」というのは、③のアプローチのことである。④は事業視点が薄いので除外すると、①②であるが、③のアプローチがプロセス制御の考え方でいうところのフィードバック制御的であるのに対し、①はフィードフォワード的、②はシーケンス制御的であるといえないことはない。

フィードフォワードでは外乱に対する制御量の把握の難しさやそれだけでは完全な制御ができないこと、またシーケンスの論理回路の設定が難しいことなど、言い換えれば、よその会社のテンプレートが自社の本当のベストプラクティスになりえるのかという問題や、標準化・最適化が本当にできるかなどの問題があり難しいアプローチであると考えている。

従って、業務プロセスに対する応答性のよいフィードバック制御が一番現実的で有効であると言っているのです。ただし、こうして開発されると業務コンポーネントが蓄積され、またブラッシュアップされていくため、こうした業務コンポーネントをモデル化あるいはテンプレートすることによって、次第にフィードフォワードやシーケンス制御の利点も取り入れることも可能になっていくものと思われる。

制御工学の話を持ち出してわかりずらかったかもしれませんが、まずは、業務プロセスをきちんと制御してから、その後より最適な方向に持っていくというアプローチを推奨しているわけです。
BPMgoal.JPG

2007年4月11日

ビジネスコンポーネント指向開発(2)

なぜビジネスコンポーネントなのか

コンポーネントという場合、どうしても部品とか、クラスライブラリーとかいったイメージで語られることが多い。これは、システムを作るうえでのシステム機能を指している。そういうものであると、しょっちゅう使う機能や、共通的な機能をまとめて外だしにする、いわゆるフレームワーク化することで、それらの再利用性を高め開発効率をあげることを目的としている。従来のコンポーネント開発といわれるものは、こうしたシステム機能寄りの発想が主なものになっているような気がする。

そうした業務非依存のアプリケーションフレームワークのレベルのものは、いまやStrutsや.NETFramworkあるいはWebの各種フレームワークなどがあり、こうしたフレームワークにあるシステム機能コンポーネントを活用すればいいことになる。問題は、業務に密着したその上層のドメインフレームワークがなかなか難しいのである。再利用性が高いドメインフレームワークはあまり見たことがない。

さて、フレームワークといってもよく分からないが、要はビジネスコンポーネントをどういう粒度で分類するかが肝になるところである。「ユーザ目線のBPM」にも書いてあるので重複するが、もう一度整理する。

業務アプリケーション(例として販売管理)
業務プロセス(受注~代金回収、営業支援、見積、在庫管理・・・)
業務サービス(受注、出荷、売上、請求・・・)
業務コンポーネント(受注受付、出荷依頼、売上登録、請求書送付・・・)

言葉の使いかたはともかくとして、このくらいの階層構造になるのではないかと思う。

これらを分類・定義していくわけだが、業務分類から入るビジネスモデリングからのアプローチだとレベルが高いうちはいいが、詳細に落とし込んでいくとその固有性や例外、特殊性などの罠にはまり、モデル化が困難になるのではないだろうか。

そこで、いい業務プロセスを作るには、業務コンポーネント主体の開発でないといけないと考えた。より普遍的な粒度で業務コンポーネントを規定し、細かい機能的なぶれはそこで吸収し、業務サービス・業務プロセスでは、差別化のための差異を表現するというアプローチだ。

いい業務プロセスを引き出す方法論、道具の提供を目指すビジネスコンポーネント指向開発こそがBPMの正しい活かし方であると考えている。

次回はこの業務コンポーネントの粒度についてさらに具体的にみていく。

2007年4月12日

ビジネスコンポーネント指向開発(3)

コンポーネントの粒度

粒度の話に行く前に前回話した業務アプリケーションの階層構造について図示したものを見ていただきたい。

例えばとして販売管理という業務アプリケーションについてのそれぞれのプロセスやサービス名を書いてある。このなかで一番小さい業務コンポーネントは細かすぎるので書いていないが、本回ではここを中心に議論する。

applilayer.jpg
この業務コンポーネントの粒度を決めるのは、その理論的な基準もないため非常に難しい。そこで考えついたのが、「書類」という単位です。

業務というのは、結局人間を中心に仕事の依頼(指示)が来て、それを受付し、何らかの処理や判断を行い、またつぎの人に新たな仕事を依頼するという繰り返しではないかと思う。その一部をITが人間の替わりに振舞ったりすることはあっても基本的な流れは人間を経由してまわっていくのではないでしょうか。

そのとき、受付-処理-依頼というアクションというかタスクというか、そういった単位業務処理は、書類で受け渡すことになるのではないのかということです。

「○○依頼書」で依頼して、その依頼書を受け付けて、処理というのは依頼書の作成・編集に相当して、例えば承認にしてもその書類に承認のサインをすることであるし、その時点でその書類が最終化され、次のステップのきっかけになっていく。

これは、何も書類になっていなくてもよくて、例えば「在庫引当」というような場合、あたかも「在庫引当依頼書」を発行したかのように振舞えばいいわけで、ほとんどのケースでそうした単位に分けることができる。そうです、この書類のライフとでも言ったらいいと思うが、一つの書類に対する「作成-編集-確定-承認」の単位を業務コンポーネントとすれば、すごく分かりやすいし、そのコンポーネントは業種・業態や環境の変化に左右されない。

そして、この業務コンポーネントを「受付」、「依頼」を介して、BPMがプロセスにしていくことになる。

flowcont.JPG


2007年4月13日

ビジネスコンポーネント指向開発(4)

業務コンポーネントのつくり

業務コンポーネントのつくりをどうするのかになるが、書類のライフと定義したということは、書類の作成から編集・確定・承認という、いわばワークフローという形態でもあると言える。しかし、ワークフローといっても、この場合は単純なもので、むしろ「状態遷移」と捉えたほうが分かりやすい。要するに、書類が作成された初期状態から、追記されたり、変更を加えられたりして、編集された状態に遷移する。それをメンバーが確定し、承認者に承認をうけて完成させるということである。

しかも、これらを逐次的な流れではなく、メンバー間での情報共有的さばきかたでやるのがこれからの仕事の進め方になるし、効率的であると思われる。Web2.0的な考え方の、参加型のアーキテクチャ、あるいは集合知の活用というところでしょうか。従って、これこそoss-CMSが本来的に持っている機能の重要な部分である。だから、それを利用するのだ。

誰かが、該当メンバーに書類の作成を宣言し、できたものをβ版でいいからすぐにアップする。それをみんなが寄ってたかって意見を言い合い改編していく、場合によっては承認者も参加しているため、承認伺いが立ったらすぐに承認・公開されるというわけだ。

それでは、具体的にoss-CMSをみていきましょう。CMSはコンテンツマネジメントシステムのことであるが、IT用語辞典「e-Words」によれば、「Webコンテンツを構成するテキストや画像、レイアウト情報などを一元的に保存・管理し、サイトを構築したり編集したりするソフトウェアのこと。広義には、デジタルコンテンツの管理を行なうシステムの総称。」ということになる。

もうちょっと技術的にいうと、「Webサイトを構築するには、テキストや画像を作成するだけでなく、HTMLやCSSなどの言語でレイアウトや装飾を行ない、ページ間にハイパーリンクを設定するなどの作業も行なう必要がある。これらの要素を分離してデータベースに保存し、サイト構築をソフトウェアで自動的に行なうようにしたものがCMSである。」であるが、CMSには拡張機能がいろいろあって、プラグインよいう形で付加できるため、広い範囲のアプリケーションに対応できる。

代表的なものをいくつかあげると、PloneXoopsWordPressMovableTypeosCommerceZenCartなどがあり、WikiやSNSも入れると数多く存在する。

今回さしあたって、「書類の状態遷移」を業務コンポーネントと定義した場合に適したものとして、Ploneを選択した。理由は、“オブジェクトの状態とユーザロール”を中心に構築されたワークフローの機能をもっていたからです。

Ploneはどのユーザが見たり実行したりできるのかを定義するのにロール(役割)を用い、そのオペレーションのすべての面においてセキュリティを組み込む。ロールにはanonymous(無名)、member(メンバー)、owner(所有者)、reviewer(レビューワ)、それにmanager(マネージャ)がある。

そして、Ploneのワークフローにはvisible(可視)、pending(保留)、published(公開)、private(私的)の4つの状態があり、それぞれのロールを与えられたユーザがオブジェクトを利用できるかどうか、また、オブジェクトが次に他のどんな状態に遷移できるのかはオブジェクトの状態によって決まってくる。

このように、ロール(役割・権限)とオブジェクト(書類)の状態を管理することでひとつの業務を処理していくわけです。こうした単位業務を組み合わせることで業務プロセスが形成されるのです。

業務コンポーネントにPloneを指名しましたが、場合によってはその他のCMSでもかまわないのです。例えば、ZenCartのような販売サイトをコンポーネントとして捉えてもよいし、Xoopsでコミュニティの議論結果をもってくるとか、応用動作は多くあるような気がします。

次回はBPMについて議論します。

2007年4月14日

ビジネスコンポーネント指向開発(5)

BPMを使う

業務コンポーネントは、oss-CMSを有効に活用し、できない部分も軽量言語とフレームワークでさくさくと開発してしまいましょうということを提案した。

さて次に、そうした業務コンポーネントをフローにしていかなくてはいけない。しかも、単なるワークフローではなく、業務フローが適正なつながりになっているか検証できるシミュレーション機能やできあがったフローの稼動を監視するモニタリング機能などが要求されてきている。そういった意味では、最近注目のBPMを使って業務プロセスを組み上げ、フロー制御していくのが有効な手段であると考えている。

BPM製品もEAIやWASから拡張されたようなものも含め、数が増えてきているが、ここでは「SAVVION」という製品でBPMを行なってみる。この製品は4年前に筆者が実際に使ったことがあることや機能的にもすぐれているので採用することにする。

ただし、この製品でなくいてはいけないということではなく、他の製品でもかまわないし、場合によってはオープンソースのものでもいいのだが、この分野はまだコミュニティが成熟していないのでまだリスクが大きいと思われる。

BPMで必要な機能とはいったい何なのだろうか。最低必要なものとしては、
1.ビジネスプロセスデザイン(シミュレーション機能付き)
2.コンポーネント(サービス)ハブ
3.モニタリング
4.実行エンジンとユーザインタフェース
であると考える。

その他、BAMだとかBIあるいはビジネスルールなどあるが、そこまで活用できる企業は少ないのではないでしょうか。ですから、まずは、適正な業務プロセスが作れて、すぐに動かすことができ、その動いている状況を把握できる仕組みがあればいいのです。

こうしたものはBPMS(BPM Suite)とよばれるが、このBPMSが機能的にすぐれた道具の集まりであることが大切で、誤解をおそれず言うと、BPMそのものあるいはBPMN,BPELとかはあまり重要視していない。

ここで、ビジネスプロセスデザイン機能についてもう少し詳しくみていく。単純に今やっている業務フローを書き出すだけでは、ビジネスプロセスデザインとは呼べない。そのAsIsのフローをシンプルで一貫化されたものにする、適正化という作業が大事である。そのためには、BPMSの中に適正化のためのチェックが自動的に行なわれることと、いろいろなケーススタディができる機能が望まれる。ここはまだ研究中でどうするかは時間が要りそうだ。

もう一つの検討課題は、PloneとSAVVIONとの接続性の問題であるが、これについては、Webサービスを用いてやることになるが、もちろん開発要素は出てくるが接続性については問題にはならない感触を得ている。

参考までに、SAVVIONのモデラーでサンプル業務フローを書いた例を載せる。
この四角の箱がアクティビティであるが、その中味はPloneで作られているといったイメージになる。そして、それぞれの線の取り合いが依頼と受付になる。それで理想的には、アクティビティの機能や線のつなぎ方に業務プロセス上で重複や迂回などのルール違反があるとワーニングしてくれるというのがうれしいのですが。

savsample.jpg
次回は、開発方法について考えてみる。

2007年4月15日

ビジネスコンポーネント指向開発(6)

開発手順

おおまかな開発手順は次のようになる。
kaihatutejun.JPG
こうした手順はウォーターフォール的に書いてあるが、実際にはスパイラル的に行なっていく。開発には、ビジネスプロセスをデザインする「ビジネスプロセスデザイナー」、業務コンポーネントの開発部分を担当する「スーパープログラマー」、実装を請け負う「ITアーキテクト」からなる開発部隊とそれを「プロジェクトマネジャー」が統括する形で行なっていく。

人数も少数精鋭で短期に仕上げて行く。また、非基幹系の業務プロセスで高い正確性を要求されないものなどはβ版で公開し、少しずつブラッシュアップするやり方も行なう。

ここで特徴的なのは、エンドユーザのひとたちと対面して開発することである。そのためには、要求が出たらすぐに実装して見せてあげることが必要となる。こうした開発方法をここでは、「対面開発(Face2FaceDevelopment)]と呼ぶことにする。ユーザの要求の”ぶれ”を早期に吸収し、手戻りの発生を防止する効果を期待する。

さて、これまでの述べてきた「ビジネスコンポーネント指向開発」の特徴と優位点についてまとめてみる。

1.ミクロワークフローとマクロワークフローに分けたこと
2.ミクロワークフローは、オブジェクトの状態遷移であると捉えたこと
3.オブジェクトを書類単位とし、それを業務コンポーネントとしたこと
4.業務コンポーネントにオープンソースCMSを適用したこと
5.オープンソースCMSにワークフロー機能とオブジェクトデータベースを内臓した「Plone」を採用したこと(オブジェクトを書類の状態遷移としたため、こうした選択となったが、違った要件では別のCMSでももちろんかまわない)
6.業務コンポーネントをBPMで組み合わせて業務プロセス・サービスにしていくこと
7.BPMはプロセスを構築するための道具と捉え、BPMSの色合いを濃くみていること
8.BPMSとして「SAVVION」を採用したこと(ただし、これも他のBPMSでもかまわない)
9.ユーザ参画型の「対面開発(Face2FaceDevelopment)」により、迅速開発と変更要求対応力を重視していること
結局、役に立つBPMというのは、こうした考え方、技術、方法論により実現できると考える。これらを図示すると次のようになる。
architec.JPG

2007年4月16日

ビジネスコンポーネント指向開発(7)

適用業務

この開発手法でどこまでの業務アプリケーションができるのだろうか。いままでの議論では、どちらかというと非基幹系業務ならだいじょうぶそうだが、基幹系だと無理じゃないのかと思われる方もいると思う。基幹系の仕組みが既にあってその周辺の業務に適用するものではないかと。しかしながら、例示したなかに販売管理システムがあったように、基幹系にも十分適用できるものと考えている。

そのとき、何をもって基幹系なのか非基幹系なのかの定義をしておく必要がありそうだ。ERPにあるから基幹系だとか生産・販売・物流は基幹系だとか、なんとなくぼやっとしていないだろうか。広義の意味では企業のPDCAサイクルを回す業務のことであるが、これだとまたよく分からないところがあるので、もっと狭めて考える必要があるような気がする。

ここで、基幹系とは、「ヒト・モノ・カネに関する確定した数量・金額を処理する」業務のことと定義する。

簡単にいえば、確定した見積金額、確定した受注数量、確定した売上等々を処理することであり、どれだけ売り上げてどれだけコストがかかったのかをはっきりさせることであり、BS/PLに反映されるアクションである。

なぜこうした境界にしたかというと、安定なシステムであるかそうでないかを峻別したいがためである。もともとコンピュータが導入された当初はこの部分しかシステムに載せていなかったわけで、その後PCが端末に登場することで、確定前の処理もPCに載せだしたために“不安定な”システムが作り出されたように思える。

例えば、受注にしても受注するまでに顧客やあるいは社内関係部署との間で在庫状況のチェックや与信などいろいろなやり取りがあって確定していくが、そのやりとりというのは必ずしも決まった手順があるわけではなくケースバイケースでの対応が多い。

こうした処理を基幹システムに放り込むことにより、例外処理や戻し処理、過剰なエラーチェックなどシステムを複雑かつ不安定にしてやしないかということである。

ですから確定前の業務はむしろ非基幹系業務ということにして分けて考えたほうがいいような気がする。また。基幹系業務で生成されたデータを使って処理する業務も非基幹系業務のひとつとして定義できる。従って、別の言い方をすると、確定前処理というのは情報共有的な進め方であるのが一般的であるため、「情報共有」と「情報活用」業務のことを非基幹系業務ということにする。

「情報共有」によりデータを確定し、それを基幹系システムに渡し、基幹系ではそのデータを使って業務処理を行い、決算データを作成し、そこで生成されたデータを「情報活用」し、次のアクションに生かしていくというシステム構造である。

さて、「ビジネスコンポーネント指向開発」は基幹系業務にも適用できるといったが、情報共有を主体とした確定前処理業務に適用するほうが向いていることから、まずはこの領域で実践し、もし有効であれば基幹系にも拡げていくことをねらう。

上述の定義からいうと非基幹系業務がけっこういっぱいあるのではないかと思う。極論すれば、今の業務パッケージをスリムにして(確定後の処理だけにして)、その周りを「ビジネスコンポーネント指向開発」で作り上げ、できたコンポーネントと業務プロセスをできるだけ再利用していくという方向性が見えてくる。

ただし、すぐには難しいのでやりやすいところから実現していくのがよいが、そのターゲットとしては見積依頼管理、顧客サービスのようなものが考えられる。また、ITILのシステム化やISO文書管理などへの適用も有効かもしれない。

2007年5月28日

ビジネスコンポーネント指向開発(8)

業務コンポーネントの種類

これまで業務コンポーネントを書類のライフとみたてて議論を進めてきた。ほとんどの業務プロセスはこの書類のライフで組み立てられるが、それ以外の業務コンポーネントも定義しておかなくてはいけない。

業務コンポーネントの性格には大きく二つあると考えている。双務的なものと片務的なものである。すなわち、双務的というのは、BPMから依頼が来てそれを受け付けて、処理を行い、その結果をBPMに渡し、次の処理を依頼するというコンポーネントのことである。一方、片務的というのは、業務プロセスの端に位置するもので、その業務処理から、プロセスが始まるもの、例えばコールセンターみたいなところからクレームがくるとかいったものや業務プロセスが終わらせるアクション、例えば結果をレガシーシステムに登録するとか、掲示するとかいったものである。

さて、書類のライフ以外の双務的なものをみていくことにする。計算型というのは、代表的なものにEXCELで集計したり、縦横計算をさせた結果を戻したい場合などにこのコンポーネントを使う。EXCELを計算エンジンに使うというのは筆者の経験ではけっこうあり得る話であると思っている。ちょっと脇にそれるかもしれないが、縦横計算を駆使する原価計算のエンジンにはEXCELがパフォーマンスがいちばん出るし、最適ではないかと思うのである。

次に外部ルールをコンポーネントとしてみているが、簡単なルールについては、BPMに内臓するか、適正化機能で実現するのがよいが、「作業割付」、「例外処理」「差し戻し」などについては、外部化せざるを得ないだろう。本来はもっと上位概念的なビジネスルールを取り込まなくてはいけないのだろうが、これまでの議論の文脈から泥臭いところでいいのではないでしょうか。

でこのビジネスルールのことなのだが、最初はよく理解できなかった。ところが、それってデシジョンテーブルですよと言われたので少し調べたら、昔、もう20年くらい前になるが、筆者が工場のプラント制御に関わっていたころにやっていたことと基本的には一緒のような気がした。例えば、発電所の選択遮断の仕組みって、ケースに応じて、系統を遮断するルールがデシジョンテーブルにセットしてあって、それに従って作動させるわけである。

さらに、例えば「ILOGJRules」というエンジンは人工知能ブームのときのAIエンジンから派生したというじゃありませんか。もう、人工知能だとかAIなんて言葉は聞きませんが、そのころははやったのです。かくいう筆者もエキスパートシステムと称して、プラントの異常検知のシステムをAIすなわちIf Then Elseの技術を使って開発したことがある。いくつかの事象をモニタリングしておいて、そこで異常が起きそうな予兆がでたらアラームを出すという仕掛けでした。何かこれはルールエンジンというよりBAMみたいな機能ですね。

少々脱線したのでもとに戻すと、書類ライフ以外の業務コンポーネントをあげてみましたが、今度はそれをどう作っていったらいいかということになると、書類ライフではオープンCMSの適用がフィットするとしたが、これだけがベストの選択肢ではない。

例えばさっき出てきた計算コンポーネントではEXCELがいいわけだし、コールセンターはそのための専用ソフトがしいし、単純なアクションだったら、それこそ「Tuigwaa(今はEscafeWebというそうだ)」でいけるだろう。ちょっとしたアプリケーションはRuby on Railsかもしれないし、コミュニティサイトはXoopsがいいとか、要は目的や要求機能にあったソフトウエア、フレームワークを選ぶことが大切になってくる。

なぜなら、できるだけ開発要素はなくし、最低限のカスタマイズで使うことが、開発生産性と保守性を向上させるからである。
BCshurui.JPG

2007年5月29日

ビジネスコンポーネント指向開発(9)

成熟度に応じたBPM導入

どの企業もBPMを導入すればいいというものではない。また、BPMSにも適用する機能の順番がある。IT化のレベルが低い企業にいきなり高度な機能を適用しても使いきれない。従って、企業の成熟度に応じて適切なBPMの導入が重要となってくる。

BPMは、その企業に合った最適な業務プロセスを構築することをめざし、プロセスの整理から始まってそれらを高度化するステップ、またできたプロセスを可視化していくステップをマネージすることが大きな目的のひとつとなる。実際には、この最適化までいくのは難しいが、業務プロセスのシンプル化、可視化のレベルをできるだけあげることが求められている。

そのために、BPMSのなかの機能をそのレベルに応じて使い分けることが必要で、BPMSはレベルアップの手段となる。一方、業務プロセスの開発にあたっては、コンポーネントの再利用あるいは共同利用化により、業務プロセスのシステム化範囲の拡大、高度化が可能になってくる。

こうしたそれぞれの要素が、各レベルでどのようになっているのかをざっとみていくことにする。

まず、成熟度の尺度をどうするかは、いちばん分かりやすい「COBIT(Control Objective for Information and Related Technology)」の成熟度モデルをもってくるのがいいだろう。

レベル1ではプロセスらしきものはあまり意識されていない状況なのでBPMは登場しない。

レベル2では一応現状の業務プロセスが描き出されてくるが、当然あるがままの状態で網羅性もないし、属人化されて隠れている場合もあるようなレベルである。こんな場合、BPMは何をすればいいのだろうか。まずは、AsIsベースの業務プロセスをプロセスデザインツールを用いてシンプルで一貫化された適正モデルに整理することだろう。
そして、その業務プロセスをワークフローでシステム化することになる。このとき、整理された業務機能から書類イメージのコンポーネントを抽出する。

レベル3では、適正化されたきれいなプロセスができあがり、ドキュメント化もなされ、かなり可視化された状態となる。ただ、まだ攻めのプロセスにはなっていないし、コントロールされているとは言いがたい。そこで、ビジネスルールやBAMにより、プロセスをより戦略的なものにしたり、また監視をすることによりガバナンスを効かすことを行なっていく。
また、このレベルでは、他システムや外部サービスとの連携が求められるためEAIのような機能が必要になる。このレベルの業務プロセスを構成するコンポーネントは標準化されて出てくるので再利用性のあるコンポーネントができあがる。

レベル4になると、経営方針や事業戦略を反映した業務プロセスが作られ、競合他社と差別化を図る武器になってくる。そのためにも、いつもプロセスの見直しが行なわれ、ビジネス環境の変化に柔軟に対応するための不断のブラッシュアップが行なわれていく。
そこでは、更に密なるシステム間連携やプロセスから生成される情報の分析などが行なわれていく。業務コンポーネントはライブラリー化され、新しいプロセスの構築、あるいはプロセス改良のために活用される。

レベル5は、そこまで達することができる企業はほんのひとにぎりで、いわゆるグローバルな超優良企業でみんなのお手本となる企業なので、ここでは言及しない。

ということで、COBITの成熟度モデルに応じたBPMを考えてみたが、要はBPMというと範囲も広いし、機能も多いし、何と言ってもひとによって様々な定義がなされているのでいくぶん混乱しているように思えるので、こんな整理の仕方をしてみたということである。
cobit.JPG

2007年7月11日

BPライフサイクル(1)

ビジネスプロセスライフサイクルとは

企業の経営あるいは事業は、会社が保有するリソース(ヒト・モノ・カネ・情報)とビジネスプロセスから成り立っている。ここではビジネスプロセスはリソースデータを使って構成されるので、データを包含したプロセスというふうに括って、ビジネスプロセスをもって企業システムと呼ぶことにする。従って、自社のビジネスプロセスをどんな構造にし、どんな機能をもたせるかは、効率的な経営や競争優位戦略などにとって非常に重要なことになる。

このビジネスプロセスを開発することについては、「ビジネスコンポーネント指向開発」で詳しく論じたが、このビジネスプロセスは作ったらそれでおしまいというわけではなく、開発したビジネスプロセスをどうコントロールするのか、継続的に保守・運用をしていくのか、そして、不断の改善をやっていけるのかというビジネスプロセスのライフサイクル全体を運用してこそ、経営に貢献できるビジネスプロセスとなる。

従って、それぞれのフェーズにおける体系や方法論を整備し、それに従って開発(Development)・制御(Control)・維持(Maintenance)・改善(Improvement)を行なっていくDCMIオペレーションシステムのことをBPライフサイクル(BPLO)と呼ぶことにする。ここで、マネージメントシステムとは言わず、オペレーションシステムとしたのは、こうしたものは、管理的というより実際に実行してこそ意味があるわけで、そうした思いをこめているからである。

そして、このDCMIについて、それぞれに基本コンセプトがあって、その考え方に従って方法論なりシステムができあがっている。

Dの開発については、今までさんざん述べているように、Business Component Oriented Development(BCOD)ということになる。Cの制御は、Information Driven Control(IDC 情報駆動制御)、Mの維持は、Sustainable System Maintenance(SSM 持続可能保守管理)、Iの改善が、Continuous Process Improvement(CPI 継続的改善運動)である。

これから、このライフサイクルに従って、どのような考え方や方法でやっていったらいいのかについて議論を進めていきたいと思います。

%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%891.JPG

2007年7月13日

BPライフサイクル(2)

プロセスということ

制御については、Information Driven Control(IDC 情報駆動制御)という概念を提示したが、この話にいく前にプロセスということについて考えてみる。

プロセスというと業務プロセスだけではなく、製造工程をさすこともあったり、それこそシステム開発の過程もプロセスである。筆者は若い頃石油化学プラントのプロセスエンジニアをやっていたので、プロセスというと化学製品の生産プロセスを思い浮かべる。この生産プロセスのライフサイクルを考えてみて、業務プロセスと対比してみる。

まず、開発だが生産プロセスの場合は最初はそれこそ試験管からは始まって、パイロットプラントを経てスケールアップされて、完成プロセスとなる。ここでは、もちろん反応方式が違うとかいったことも大きいが、このスケールアップというのが重要なファクターになる。業務プロセスの場合はいきなりどんと全社システムの導入のようなやり方になる。

システム開発ではこのスケールアップというステップがとれないし、これは生産プロセスも同じだが、一部を動かして順次全体に拡げていくというのも、無理すればできないこともないが難しい。ここが、システム開発のやっかいなところで、そのため導入時にはいくつかの弊害がでてくる。

例えば、業務間あるいはシステム間の全体整合をとるためにすごい苦労をしたり、プロジェクトの最後にはやみくもにコーディングして後で泣くとか、長いテスト期間をとるとか、そういった一発勝負的な開発が多いような気がする。ただし、これは今までの話であって、これからはこの問題についても解決手段として、BPM on SOA
が有効になる可能性があると思っている。

ここで忘れてはいけないのが、全社リソースデータが一元管理できていることが重要な前提となることである。スケールアップや順次稼動の場合、個別にデータベースを作っていたのでは、整合性のとれない“サイロ”システムを生み出すだけになるおそれがあるからである。

さて、生産工場などにおけるプロセスはどのように可視化されているかというと、実物の機器や配管などが目で見えるというのも大きな違いであるが、関係者がコミュニケーションできる共通の図面の存在も違いのひとつではないだろうか。

プラントでは、オペレーター、スタッフ、保全担当、安全担当などの人々は、何かあると必ずP&ID(Piping & Instrument Diagram)というものを見ながら話をする。文字どおり、プロセス流体の流れ、遷移状態、プロセス変数などがすぐに分かるようになっている。それと、配管図や機器図などを参照していけば、プロセスは可視化できるのである。

翻って、業務プロセスはどうか。このP&IDに当たるものがない。配管図や機器図に当たるものは、ネットワーク図やハードウエア構成図などがあるが、プロセスの動的な部分も含めて、流れの状態がわかるような図面がないように思える。業務フロー図、業務マニュアルがあるじゃないかといわれるかもしれませんが、それで制御できるのだろうか。

ここで強く言いたいのは、同じプロセスという概念で扱うのであれば、ただ開発したらあとはエンドユーザのひとにおまかせと言うのではなく、その後の制御、維持、改善を考えたライフサイクルを意識することが大事だということである。

特に、生産プロセスの場合は、制御というところにすごく重きを置いているわけで、そのためには、プロセスの設計には現場のオペレーションする人たちのかかわり方が強くある。自分たちがオペレーションしなくてはいけないプロセスは自分たちで考えようじゃないかという当たり前の話なのだ。

従って、業務プロセスの設計・開発にもあとで実際にそのプロセスを使ってオペレーションする人の参画を濃いものにしていかなくてはならない。これは、開発側の問題でもあり、ユーザ側の問題でもある。もちろん、ユーザ参画はいまでもやられているプロジェクトもあるが、もう少しその気になった参画と、あとの“制御”という考え方を取り入れた設計を行なう必要があると思う。

制御だけではなく、維持、改善というプロセスについても、生産プロセスの場合はかなりシビアに管理している。従って、業務プロセスの場合もこうしたことを含めたライフサイクルが非常に重要なことになる。

2007年7月19日

BPライフサイクル(3)

プロセスの制御

化学プラントのようなプロセスやその他の生産プロセスでは、プロセスを制御して生産性をあげるだとか、安全・安定な製品を作るということが重要だという話をした。ところが、ホワイトカラーの事務処理のような業務プロセスでは、プロセスを制御するという考え方が薄いような気がする。これまで、この領域ではコンピュータシステムを作ることに汲々としていて、しかもできたらそれで終わりみたいなところがあって、画面のレスポンスやバッチの処理時間のようなことには敏感だが、これはシステムの制御であって業務プロセスの制御ではない。

BPMはプロセス制御という考え方を取り入れてきているが、制御とはなにかという定義の問題も含めてまだバラバラのような気がする。プロセスのある部分での停滞を監視して、停滞箇所での処理を促すのか、系のパフォーマンスを算出するだけなのかというように、何をモニタリングして、その結果をどのように生かすのかが定まっていない。

それはBAM(Business Activity Monitoring)でしょという声が聞こえてきそうだが、BAMというのは、リアルタイムでモニタリングして何か異常事象が発生したらワーニングしたり、対応アクションにつなげたりすることなのだが、ただこれだと制御というイメージではなく、プラントで言えば安全装置を働かせたり、バイパスしたりといったことに相当する。だから、制御というのはプロセスが安定して動くようにどうするかということとその異常時対応の両方で成り立つ。

さて、制御には2段階あって、まず系を安定させる制御と異常時の対応ということなのだが、BAMの機能で言われていることを本当に有効に活用できる企業ってどれだけあるのだろうか。BAMの目的は、重要なビジネス目標をモニターし、オペレーション上のリスクを予知し、事後事象からアクション開始までのタイムラグを低減することなのだが、オペレーショナルレベルとビジネス目標が必ずしも密接につながっていることは少ないことや、異常事象とプロセス変数の相関も難しいし、そこから因果関係を見つけて操作変数を動かすのはもっと難しいことから、うまく(自動的に)使われるとは考えにくいのは筆者だけだろうか。少なくとも、相当成熟度レベルの高い企業にしか適用は難しいと思う。

なお、BAMは、またBIと組み合わせて改善につながるための監視機能にもなる。そこについては改善の項で言及する。

一般の会社においては、情報だけはもらうが、それを使ってどうするかは、結局人間の判断というのが現実的であろう。だから、プロセスをスムーズに回すにはどうしたらいいのか、システムはそれにどう寄与するのかという制御を考えたほうがよさそうだ。

それは、この方法論では「情報がアクションを誘導する」仕掛けである。具体的には、まずはCMSによるコラボレーションサイトである。これまでの、仕事のやりかたやシステムの構成は、どちらかというと逐次的な処理形態をベースにしている。すなわち、何かの処理が終わると次に回してという風に順番に仕事をこなしていく。しかも、その処理の受渡しは、次の処理を行なう人が情報を取りにいくプル型の流れになっていたのが多い。こうだと受け手が情報を見ないとそこで停滞がおき、相互の連携が切れてしまうので、全体の系の動きがコントロールできなくなる。

従って、これをプッシュ型に変えて、さらにその情報が関係者全員に分かるように公開することで、誰の手にボールがあって、次はどこに投げられ、どこで止まっているかが見通せるようにすることが大事だ。そうすれば、人間の目ではあるが、プロセスを円滑に機能させるためのドライビングフォースになる。一種のピアプレッシャーである。こうした、情報共有型業務処理では、人間の目による制御機構が働くことになる。

一方、マクロワークフローを回す部分では、システム的なパフォーマンス監視での制御となる。それぞれのプロセス変数に対して、閾値を決め、それを越えるようならワーニングを出す。ここは、定型的、安定的な処理になるため、こうしたシステム的な制御が有効になってくる。

何回も繰り返してきていることだが、業務処理のタイプ、すなわち、定型的かそうでないか、安定なのか不安定なのかといったことにより、その開発方法、稼動プラットフォームが違うのと同じように、その制御の仕方も違ってくるのだ。その制御方法こそ、情報駆動制御(Information Driven Control(IDC))ということになる。

2007年7月24日

BPライフサイクル(4)

プロセスの維持

さて、業務プロセスを開発して、制御したら、それを維持していかなくてはならない。日常的な運用や保守である。それは、ビジネスプロセスそのものの維持とそれを動かしているシステムの維持という二つの側面を持っている。

システム屋さんは、この前者のビジネスプロセスの維持という観点が薄いというか、ないのではないでしょうか。しかし、重要なのは、たえず事業に貢献できるプロセスであり続けるかというチェックである。単にユーザから変更要求があったら、それに対応すればいいという態度では、プロセスの劣化も起こるだろうし、つぎの改善というアクションにつながっていかない。ですから、ビジネスプロセスの維持管理は、BPライフサイクルでも軽視できない大事なサイクルである。

それでは、ビジネスプロセスが劣化するとはどういうことなのだろうか。劣化することがあるのだろうか。ビジネスプロセスそのものの劣化はないのではないでしょうか。腐るわけではないし、壊れるわけではないので。たとえば、プロセスに慣れてきたため、注意を怠って、誤って出荷先を間違えたなんてことが、プロセスの劣化とは言いがたく、それはオペレーションの問題でどちらかというと制御の領域と考えられる。

となると、ビジネスプロセスの劣化というのはどうも、法や制度の変更も含めたビジネス環境が変わったのでそれに対処するためにプロセスを変えていかないとビジネスが維持できないというケースがこれに当たるのではないでしょうか。改善とは違って、受身的な対応である。人事システムのように、毎年法改正や組織改正があってそれに対応するための変更が必ずあるというものもある。ですから、どこの会社でもあると思うが、年末調整の前や組織が変わるある時期だけ忙しくて、そのほかはメンテはほとんどないということがある。

他のシステムでも、人事ほどではないにしても、法や組織改正による変更が発生する。それ以外にも、競合他社に離されないためにプロセスを変えざるを得ないだとか、画期的なサービスや技術が登場して、それに対応しないと取り残されてしまうとかといった、ビジネスのレースから脱落しないための維持管理ということも非常に重要なことである。

こうした素早い変更ができるためには、プロセス自体が変更に強い構造になっていなくてはならない。機能とプロセスを、そしてデータを分離して、疎結合にしておくことで対応することになる。こうしたSOAのシステム基盤こそが、保守性の向上に大きく寄与するのだ。

さて、次はシステムの保守という問題である。ただ、これは従来からやられていたことだから、ここであえて採りあげるつもりはないが、ひとつ注意しなくていけないのに、オープンソースのソフトウエアの保守をどう考えるかがある。オープンソースは、使うのは無償ということもあり、開発時はコストもかからないからと飛びつくが、そのあとの保守をどうするかは考えていないことが多い。

バージョンを上げたら今のアプリケーションが動くかどうか誰がみてくれるのかとか、そもそもそのオープンソースのコミュニティがなくなってしまうというリスクもあるわけで、導入コストだけで判断すると危険である。ですから、まずはオープンソースといえどもメジャーでコミュニティも活発で、特に日本の活動がちゃんとされているものを選ぶのが大事だ。

そして、ソースコードをある程度読める要員を確保することが望ましい。本を書くのは難しいが読むのはそう難しくないように、プロダクトをクリエイトするのは難しいが、ソースを読んでどんなコードで成り立っているくらいは分かると思う。そういう人であれば、コミュニティへ参加して教えてもらうことも可能だ。もし、そうした人材も確保できなかったら、お金を払ってその橋渡しをしてくれる人か、会社を確保すればよい。

だから、オープンソースだとお金がかからないということはなく、維持管理にはコストがかかるのだ。これは商用のソフトウエアと同じで、自己責任の範囲を広げてコストダウンをするのか、コストをかけて責任を回避するのかということである。そこは、自社の人的リソースの状況あるいは対象アプリケーションの性格などによって、どちらを選択するか決めればいい。

「ビジネスコンポーネント指向開発」において、オープンCMSを採用した理由は、フロントの確定データを作るまでのコラボレーション業務に適用しているので、言ってみれば、重要度が落ちる領域であるからである。極端な話、そこで不具合があって動かなくなっても、電話とメールで会話して、手で入力すればすむのであって、そんなクリティカルなことではないのである。

逆に、その確定データが投入されたあとのシステムの不具合は、影響が多くなるため、商用ソフトウエアを利用する考え方をとっている。

ですから、こういうところにも適材適所のシステム構造を設計していかなくてはいけないのだ。

何と言ってもビジネスプロセスは持続可能でなくてはならない。そのためにもこうしたSustainable System Maintenance(SSM 持続可能保守管理)という考えかたが重要になってくる。

2007年8月 1日

BPライフサイクル(5)

プロセスの改善

さていよいよ最後のプロセスの改善徒言うことになる。これは、昔BPR(Business Process Reengineering)というやつに近い。当時のBPRはいきなり業務改善のような話だったり、会社全体の大きなプロセスを対象にしたりしていて、何となくついていけなくて消えていった。今またBPMという形でつながってきている。BPMの場合は、プロセスのモデル化をして、そこからかいぜんというアプローチだから以前に比べると地に足がついたことができるような気がする。

ビジネスプロセスは、環境の変化や新しい技術の出現、経営からの要求度など、経営も変化していくのに合わせて、プロセスも進化していかなくてはいけない。そのために重要なことは、現状をよく監視し分析することである。今何が起きていて、どういう問題があるのか、そういったプロセス全体の状況をよくモニタリングすることから始めていく。それを可能にしてくれる機能がBAM(Business Activity Monitoring)である。

また、広くBI(Business Intelligence)もBAMの一種と考えてもいいような気がする。ただ、両者の違いは、リアルタイム的か定期的かということと、対象が事象なのかデータなのかの違いがあるが、そう大きな差はない。両方とも必要なソリューションである。だから、BAMでどこかのプロセスに停滞はないのか、納期に遅れないか、このままだと問題が起きそうだとか、そういった現時点での対処につながる監視を行なうのである。

これは制御に似かよった話である。在庫が切れそうだからアラートを出すなんていうのは制御のレベルである。BAMはもう少し改善につながるための監視であると考える。ただし、どんなプロセスでもBAMの効果が出るとは限らない。そんなにリアルタイムにプロセスを監視していて、瞬時に対応するなんてことをやる業種ってなんなのだろうか。ジャストインタイムのようなことをしているところなのか、よくわからない。

一方、プロセスから生み出されて様々なアクションの結果がデータとなって蓄積されるので、それをBIにより解析し、相関関係あるいは因果関係を探っていくことになる。BIについては、BPMというところからの入り方というより、どんな企業でも大なり小なり、データ解析は必要であり、そこから改善の芽が生まれてくる。だから、データ・情報活用という観点でみていけばいい。

このBAMというのはどうもある程度成熟した企業がやっと取り組めるようになるソリューションであると思う。最初にBPMに取り組んだ会社は、いきなりBAMまでいかずにせいぜい何とか自分たちのプロセスをコントロールすることが大切である。そこで系を安定させておいて、次に問題箇所を見つけ出し改善していくというステップだ。

いずれにしろ、こうした取り組みは不断の努力によって成しとげられるので、Continuous Process Improvement(CPI 継続的改善運動)として地道でいいから自然に続けられる仕掛けが大事になってくる。

2007年10月19日

ビジネスコンポーネント指向開発(10)

ソフトウエア工学的な開発手法との対比

久しぶりに開発技法の話です。

この「ビジネスコンポーネント指向開発」の技法は世間的には何という名前なのだろうか。いわゆるソフトウエア工学では、従来の構造化分析、構造化プログラミングといった構造化手法からいまはオブジェクト指向というふうに変わってきていると書いてある。

構造化技法というのはDFDを書いて、プログラムを関数という「部品」に分割して、それを組み合わせてソフトウエアをつくると言われてもだいたいわかるが、オブジェクト指向はよくわからない。オブジェクト指向で、「データ」と、それを操作するための「メソッド」の組み合わせて、それをカプセル化したものが「オブジェクト」ですと言われても、これって構造化手法のこととどこが違うのと思ってしまう。

一方、オブジェクト指向はプログラミングから来ているから、分析とか業務設計には向いていないとも言われている。DOAをやっている人がよく言う。確かにUMLでビジネスを書かれても、特にユーザは理解できない。ユーザに理解してもらえない手法は、システム屋のマスターベーションでしかない。だからといって、DOAのER図がユーザから理解されるかというとこれもなかなかむずかしい。

DOA(Data Oriented Approach)というのは、和製英語で堀内一さんが最初に言い出したものでが、それまでのPOA(Process Oriented Approach)というものは今はどうなっているのだろうか。

こうしてみると開発手法は、構造化手法、オブジェクト指向、DOA、POAとあるが、これだという決定打はないように思える。いまは、オブジェクト指向ばかりのように見えるが、それだけで満足できるものができるかどうかあやしい。筆者は、それぞれの手法を適材適所的に使うことを提案したい。言い換えれば、それを実行しているのが、「ビジネスコンポーネント指向開発」なのである。

システムは(ビジネスといってもいい)、再三言ってきたように機能とプロセスとデータから成り立っている。これらを設計するのに、基本的に機能はOOA(Object Oriented Approach)、プロセスはPOA、データはDOA、全体を「構造化」するという考え方である。ここでいう「構造化」というのは、構造化手法ということではなく(いわゆる構造化手法というのは、POAやOOAに引き継がれている)、SOAの概念で柔軟な構造にするという意味です。

ここで注意しなくてはいけないのは、全く別々にやるわけではなく、主としてその手法を用いるといった程度のものである。逆に共通するもの、あるいは交差するものもある。

例えば、機能といった場合、いまオブジェクト指向で言う「オブジェクト」という概念をあてはめているが、POAでは「アクティビティ」であり、DOAでは「エンティrティ」に相当する。だからそこでお互いが結ばれていくというイメージです。もう少し説明を加えると、OOAで実ビジネスおける概念をしっかり定義することであり、そこから生まれたアクティビティ(コンポーネント)をPOAでシンプルなプロセスにし、DOAでリソースデータを中心にしたデータインフラを構築するというのが正しい方向である気がします。

この考え方を「ビジネスコンポーネント指向開発」において具体的に説明すると、まず「オブジェクト」を書類というふうに定義しています。ビジネスではほとんどの場合、書類の受渡し(紙ではなくても)により仕事をしています。だれかに依頼され、それを処理して、つぎに渡すという流れですが、それは書類という「オブジェクト」を作成し、できたものが「クラス」と言ってもいいかもしれませんが、その書類が転記されていくことが処理に当たると考えています。

この「クラス」が、「アクティビティ」となってBPMに飛んでくるわけです。BPMではPOAに考え方によりプロセス中心に構築していきます。「ビジネスコンポーネント指向開発」では単なる「アクティビティ」ではないもう少し、広いサービスのようなものも対象にしますから、それらもひっくるめて「ビジネスコンポーネント」と呼んでいるのです。

次に、データとの関係を見て行きましょう。DOAでは、ER図を書くことでデータとプロセスが表現できることになっています。DOAでは、まずリソースデータとイベントデータに分けて設計します。リソースデータは、人・物・顧客などの、いわゆるマスタデータで、イベントデータは、「○○する」という言い方ができる、例えば、受注、出荷、購買といったものがこれにあたります。そのイベントデータは時系列的においていきますから、プロセスを表現していることになります。

とういうことは、それでプロセス設計ができるじゃないかと言われますが、なかなか分かりにくく、ユーザには難しいのです。従って、DOAでリソースデータベースの設計を行ない、BPM側はそのリソースデータを使ってプロセスを回し、そこで発生したイベントデータはBPM側で作るというのがいいのではないだろうか。

このデータベースの設計と蓄積されたデータの活用も含めたデータベースマネージメントについては次回に提示する。
 

2007年10月22日

ビジネスコンポーネント指向開発(11)

データベース

プロセスだけではなく当然データベースの設計、構築もしていかなくてはならない。データベースは一種類だけではなくその用途に応じて構築されるべきである。

大きく二つに分かれる。インフラ系のデータベースとイベント系のデータベースである。イベントデータは、前回にも書いたようにプロセスに結びついたトランザクションデータとなります。ですから、このデータベースはプロセスの設計時にそのアクティビティに付属するデータとして捕捉されます。Savvionではデータスロットに格納されるデータということになります。

ここでの議論は主にインフラ系のデータベースについてとなります。インフラ系のデータベースはリソース系と参照用データベースにわかれます。リソース系というのはマスタデータ、参照用というのはデータウエアハウス(DWH)と言い換えてもかまいません。

DWHは、さらにセントラルDWH(エンタープライズDWH)と用途に応じて絞り込んだデータマートに分解されていきます。

さて、「ビジネスコンポーネント指向開発」では、業務プロセスが可視化され、そのプロセスから生じたデータがイベントデータベースに格納されて、そのデータをモニターしてプロセスの制御を行なったり、パフォーマンスの解析に使ったりする。

また、エンタープライズレベルでは、BIツールを使ってデータ分析を行ない、BSCなどの業績評価や管理会計につながっていく。筆者は管理会計というのはデータウエアハウスだと思っていて、静的データはリソースDBから、動的データはBPMのイベントDBからもってきてマッピングするのではないでしょうか。

このように、データベースもその使い方や性格に応じて構造化しておき、相互の連携を行なうことが大事である。場合によっては、EAIのようなツールを使うことになるかもしれません。

特に、リソースデータ(マスタ)は、One Fact in One Placeの原則をきちんと守り、システム開発の最初に構築しておくことが望ましい。

最近、マスタデータマネジメントシステム(MDM)という言葉を見かけるになってきた。意外とこのマスタデータを運用・管理するのは手間がかかるものである。多くは人手を介して泥臭くやっているのではないでしょうか。エンドユーザ自身にやってもうというのもあるかもしれないが、いずれにしろここはシステマチックにいきたいものです。

ここでもBPM-CMSを使ったシステム化を推奨します。すなわち、マスタの追加・変更をCMS上に流し、そこで承認を得たものがBPMを通してマスタに飛んでいくというイメージだ。システム部門ですぐにできるのでそこからはじめたらどうだろうか。

BPMというと、どうしてもプロセスに目が行ってデータベースがおろそかになるが、データベースありきが前提というわけには行かない場合もあるので、プロセス設計と同じようにデータベース設計も重要であることを忘れないようにしたいものだ。

2007年12月 5日

ビジネスコンポーネント指向開発(12)

組織のアクティビティと人間のアクティビティ

ビジネスプロセスにはマクロワークフローとミクロワークフローがあるということを言ってきて、ミクロワークフローは、人間主体のグループとしての情報共有型業務であることも言ってきた。

ところでさらにもう少し踏み込んで考えると、個人の業務管理はどうなのということがある。この個人の業務管理というのは、フローではなくタスク管理ということになる。すなわち、個人のタスクが、いまどういうものを抱えて、それがどんなステータスなのか、期限がいつなのかというようなことを管理することが重要になる。まあ、TO DO管理ということかしれない。

一方、以前業務コンポーネントの種類ということで、書類という定義だけでは収まらないこともあって、プロセスの開始点、例えばコールセンターのクレーム受付といったものは、書類化以前のアクションで、こうしたものをどうするかという課題があった。

また、プロセスの途中でも、「計算処理」だとか「作業割付」みたいな割り込み処理のようなものが入る。それは、別のサービスとして処理を依頼して、その処理結果を戻してもらうということがある。それをどういうやり方、あるいはどういうサービスツールで実現するのかという課題もあった。

計算処理は大体がEXCELでいけると思うが、ほかのところをどうするのかが課題であったが、個人のタスク管理という視点のツールが多分これを満たしてくれるような気がする。すなわち、ここでもガチガチスタイルの管理ツールではなくもうちょっとゆるやかなものです。

そうなんですね、人間関係に入ったら、人間の脳コンピュータに任せて、機械コンピュータはおとなしくしているというのが望ましい態度なのではないでしょうか。そういう意味では、ゆるいシステムがいいのだが、ただそれだと野放図になっても困るので、ある種のルールあるいは作法がそれを規制する姿でいいんじゃないかと思う。

それで、最近「グルット」というツールを注目している。イッシュートラキングシステムと名乗っているけど、まあタスク管理システムでいいんだけど、要はEXCELライクの表で自分のタスクを管理するソフトなんだけどゆるいからいい。

システムの歴史は、システムが人間を支配する、あるいは人間の振る舞いを表現できるというように動いた気がする。しかし、現実は、システムは人間を超えられないという当たり前の事実に向き合っている。システムの生物化がいまだにできていないということである。

じゃあどうするかというと、もっと人間と融和した関係を“システマチック”に作ることが大切なのではないだろうか。プロセスのつなぎに人間が介在するという言い方もできる。

だから、これからの「BPM+web2.0」がその傲慢さを反省し、人間との共生を目指したシステムになりうることを期待するのである。
 

About ユーザ目線のBPM

ブログ「mark-wada blog」のカテゴリ「ユーザ目線のBPM」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

前のカテゴリはカジュアルBPMのすすめです。

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

Powered by
Movable Type