ＳＣＭパッケージソフト 開発勉強日記です。
SCM / MRP / 物流等々情報を集めていきます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
ビジネスプロセスの標準規格
今日のビジネスプロセス標準規格
たいていの企業のたいていの社員は、仕事の標準規格について気に掛けることがない。彼らの仕事は、それをどのように遂行するかに関する共通の理解と合意を得た多くの約束事と協定に基づき、極めて単純化されたものである。彼らは、その事実に思いをはせることなく、単に仕事をこなしているにすぎない。
- PR -
車の運転では、道路の右側を走ることと左側を走ることの間に、何の違いもない。しかし、特定地域内では、そのいずれを選択するかについて、すべての人間の合意が欠かせない。同様例で別の観点からいえば、ネジ頭の形状数を限定し、2セットのドライバーでほとんどの場合に対応できることで、われわれ全員が恩恵を被っているのである。
筆者（ポール・ハーモン）は、ほかのアドバイザリ・Webページ※1で、ジェフリー・ムーアの技術導入ライフサイクルモデルについて論じたことがある（図1）。
※1 訳注：本稿を含め、筆者が月次発信するBPM論考シリーズ
簡潔にいえば、イノベーターの範疇（はんちゅう）に属する企業は大学や研究機関から直接新しい技術を採用し、それを大きな競争力の源泉となる突破口として活かそうとする。その技術を役立てる方法を見いだすために、膨大なリソースを積極的に投じている。早期導入者は少し遅れて技術を採用し、競合企業より先に用途を開発することで競争優位に立とうとする。
早期多数派に位置する企業は、新技術を導入する前に、その技術の有効性が明らかになるまで待つ。それにより、新技術の実験と未成熟なツールとの格闘に必要なコスト高の努力を回避する。さらに注目されるのは、彼らが標準規格が整うまで待とうとすることだ。別のいい方をすれば、少なくとも技術領域における標準規格開発は、技術ライフサイクルの早期導入者フェイズの期間中にベンダと先行的ユーザーによって遂行される活動なのである。
図1 ジェフリー・ムーアの技術導入ライフサイクル
標準規格開発への取り組みに関心を持つ企業は、そう多くない。たいていの企業は、技術の普及体制が整うころには標準規格も完成しているはず、と見込んでいるのだ。数年内に有効な標準規格が作成できなかったために、キャズム※2に落ち込み消え去る技術もある。
※2 編注：リリースできなかったとすれば、死の谷というべきかもしれない
標準規格について考えるときに念頭に置かなければならないもう1つの事柄は、デファクト・スタンダードとデジュアリ・スタンダードの違いである。デジュアリ（公的な）・スタンダードは、標準規格機関や業界コンソーシアムによって設定される。片や公式的取り決めを求めないコミュニティによって定められるのが、デファクト（実際上の）・スタンダードだ。
例えばMicrosoft Windowsは、90％以上のPCユーザーが依存するマイクロソフトのOSである。それはOSのデファクト・スタンダードであり、PC用ソフトウェアを売ろうとするベンダであれば、それを支持せざるを得ないであろう。
複雑で急速に進展する環境下では、デファクト・スタンダードの方が、デジュアリ・スタンダードよりも重要である場合が多い。デジュアリ・スタンダードの決定には、通常、より長い時間がかかるからだ。別のいい方をすれば、有力なベンダが一般の標準規格に従えない場合に裁定を下すのは市場であり、結局はデジュアリ・スタンダードとなるベンダが勝利を収めるのである。
これらの考察を念頭に置き、今日のビジネスプロセスに関する標準規格について少し述べたい。この論述の整理の仕方として、標準規格を利用する立場に応じ、それらを3つの大きな枠組みに分類してゆくことになろう。
まず、エンタープライズレベル標準規格は、ビジネスマネージャが、事業活動を分析し体系化するために使用する。
プロセスレベル標準規格は、ビジネスマネージャとビジネスプロセス担当者が、ビジネスプロセス変革プロジェクトの実施に臨む際に使用する。ビジネス・プロジェクトの実施には多様な立場の個人が携わるため、この領域の取りまとめが最も難しい。ある場合には、ビジネスマネージャがビジネス改革プロジェクトの実施に当たる。一方、ITビジネス・アナリストその他のIT関係者がプロセス自動化プロジェクトを遂行するといった実態がある。
実施レベル標準規格は、プロセスにかかわる問題のソリューション開発担当者によって使用される技術を特定対象とするものだ。この領域の標準規格の大半は、ソフトウェア開発の方法あるいはソフトウェア・ツールのインターフェイスの方法を定めたIT標準規格である。既存の、あるいは現在開発途上にあるビジネスプロセス標準規格のすべてを包含するのはほとんど不可能なことだが、大局的見地からの概観は持ちたい。
いうまでもなく、筆者はこの論述の構成と標準規格の分類を筆者自身の経験に照らして行った。これらの標準規格を、筆者と異なる様式で整理される方もおられるに違いない。また、筆者の考えで分類した標準規格の中には、ほかの範疇に位置付けてもよいものもあるだろう。いずれにせよ、概観を簡潔に提示することが必要なのだ。
エンタープライズレベル・ビジネスプロセス標準規格
エンタープライズレベル・ビジネスプロセス標準規格は、ビジネス・パフォーマンスの概要把握、評価、およびマネジメントの体系化を支援するツールとして、エグゼクティブとシニア・ビジネスマネージャに使用される。さらに、エグゼクティブ・コミッティ傘下にBPMグループを設置し、同標準規格をマネージャのパフォーマンス評価とプロセス介入優先順位設定のツールとして用いている企業もある。
恐らく、エンタープライズレベルで最も広く用いられているビジネスプロセス標準規格は、キャプランとノートンのバランスト・スコアカード（BSC）による経営評価アプローチであろう。これは事実上のデファクト・スタンダードであり、多様な様式で用いられていると思われる。しかし、多様ではあっても、キャプランとノートンのアプローチの改変版の間には十分な共通項が見られる。もしバランスト・スコアカードを用いているかと問われた場合、たいていの企業は直ちに「イエス」か「ノー」の回答ができるはずだ。
エンタープライズレベルにおいて、最も注目されるビジネスプロセス標準規格が、サプライチェーン・カウンシルのSCORフレームワークと方法論である。SCORは、複数企業にまたがるサプライチェーン・プロセスを構築し評価するためのツールとして、サプライチェーン・マネージャたちによって開発された。バリューチェーン全体の定義、ベンチマーキング、および評価を行うための標準規格として、急速に普及している。その増幅版では、SCOR+とSCOR/DCOR/CCOR（サプライチェーン・モデル、デザインチェーン・モデル、カスタマーチェーン・モデルに対応）の、いずれかの名称が使用されるようになった。
今後数年間には、プロセスセントリック・アプローチを導入するシニア・エグゼクティブが増加する。これに伴い、SCOR+の重要度も増すに違いない。
VCORは、SCOR+と非常に類似点が多いが、もう1つの異なるアプローチだ。eTOMは、テレコム業界向けに特別に作成されたフレームワークである（今後は、ほかの業界でも、同様のフレームワークが作成される可能性が大きい）。
エンタープライズレベルで時々用いられる、もう1つの標準規格が、ソフトウェアエンジニアリング・インスティチュート（SEI）のケイパビリティ成熟度統合モデル（CMMI）である。CMMIをITプロセスのパフォーマンス評価に用いているケースが圧倒的に多く、この場合には、CMMIをプロセスレベル標準規格と位置付けるのが妥当であろう。しかし、一部の企業では、すべてのビジネスプロセスを評価し全体組織の動向を見極めるために用いられている。この場合には、エンタープライズレベルのツールとして機能していると見てよい。
さまざまな米国政府機関の支柱になっているのが、連邦エンタープライズアーキテクチャ・フレームワーク（FEAF）だ。FEAFは、ある意味ではエンタープライズ・ツールであり、いくつかの機関がその位置付けで用いている。しかし、ITアーキテクチャ構築のアプローチとして用いられることがほとんどで、この場合には、ザックマンのようなIT実行標準規格の範疇に含められるであろう。
図2に、筆者が想定する主要なビジネスプロセス標準規格の位置付けを示しておく。
プロセスレベルは、全体がプロセスのリデザイン／実施プロジェクトの集積である。このレベルの標準規格は、具体的なプロセスの改革に当たるマネージャ、従業員、ビジネスアナリスト、およびヒューマンパフォーマンス・アナリストを支援する。
これまでに、プロセスレベルで最も広く用いられてきた標準規格は、シックスシグマであった。企業や標準規格機関ごとに多様に定義されてきた、もう1つのデファクト・スタンダードでもある。しかし、たいていのシックスシグマ改変版の間には、容易に認識できる、ファミリとしての類似性がある。シックスシグマは、汎用的プロセス改善手法（DMAIC）と、プロセス改善チームがプロセスの改善に適用できる多彩なツールを備えているのだ。
リーンはプロセスフローの無駄の除去に重点化した別個の手法であり、一般的に、シックスシグマ・チームが取り込むべきツールの1つだと考えられている。従って、恐らく、この標準規格は「シックスシグマ／リーン」と称されるべきなのだろう。
いずれにせよ、多くの大手企業が膨大な数の従業員に対してシックスシグマ教育を行い、シックスシグマ／リーン・アプローチにのっとった数多くの改善プロジェクトを定期的に実施しているのである。
シックスシグマとほぼ同等に普及しているのが、ISO 9000だ（この標準規格は9000番台に関し、多くのバリエーションを持つが、一般的にはこの呼称で通っている）。突き詰めれば、ISO 9000は国際標準規格機構が定めたビジネスプロセス定義の仕様である。ヨーロッパの多くの大手企業と政府が、ISO 9000を用いてプロセスを定義することを企業に義務付けている。
残念なことに、この標準規格は、いまや「チェックリスト」項目でしかなくなってしまった。ISO 9000の文書を手早く作成し、それを棚さらしにしている企業がほとんどだ。今日のビジネスプロセス業務に合わせてISO 9000の意義を高めようとする動きはある。しかし、現状では、企業におけるプロセスの実際的運用に対するISO文書のインパクトは、ほとんど見られない。
米国では、たいていの企業がサーベンス・オクスリー法（SOX法）に対応するための文書作成に取り組んできた。重要な財務上の意思決定に結び付くプロセスを追跡できる体制が整っていることを示すよう、企業に義務付けた米国内法である。ISO 9000と同じく、サーベンス・オクスリー法は、社内プロセスの把握を大きく前進させる機会を企業に与える。しかし、やはり、あまりにも短時間内に処理されてきたのがサーベンス・オクスリーの実態だ。やがて棚の上でISO 9000関連文書のそばで眠る貯蔵品になってしまう可能性が極めて大きい。
最近、OMGがルールの標準規格（および、それに関連するビジネスモチベーション・モデル）を公開した。元はビジネスルールズ・コミュニティ（BRC）で開発されたものだが、企業で用いる語彙、方針、ビジネスルールを定義するための標準規格を定めている。この領域では金融機関の取り組みが非常に活発であり、この標準が、やがて金融機関におけるオントロジーとビジネスルールを確立するためのてことして活かされるであろう。
特定の業界あるいは領域に特化した、いくつかのビジネス・フレームワークは、プロセスチームが既存ビジネスプロセスのデザインと評価を行うのに役立つ。ITIL（ITサポート・プロセスの標準規格）とCoBiT（ITマネジメント・プロセスの標準規格）は、その好例だ。双方に対し、ITプロセスの全社的標準化を望む企業からの関心が高まっている。
この数年、ビジネスプロセス・モデラーが多種多様なワークフロー表記法を用いてきた。その代表例が、IDEF0とラムラー・ブレーシュである。普及度の高いプロセスモデリング・ツールのほとんどが、これらの2つの表記法を支持し、その自社版を提供している。
しかし、いまのところ、ビジネスマンの大多数がよりどころとするデファクト・スタンダードはない。フロー図によるビジネスプロセスの文書化と、遂行すべきタスクを記述した図の読み方に関する社員教育を行っている企業が多いという考察に至れば、標準的ビジネスプロセス表記法に有用性を見いだすことになるだろう。
現時点で最も推奨できるのが、BPMI/OMGのビジネスプロセスマネジメント表記法（BPMN）だ。大手プロセスモデリング・ベンダが結成したチームにより開発されたという点、および、コア・バージョンでビジネスマンが必要とする基本的表記法を提供している点で評価できる。半面、ビジネスプロセス実行言語（BPEL）を作成する機能まで持たせたために、明らかにビジネスマンには必要のない、あるいは理解できない多くの表記法が含まれている点はいただけない。
さらに、現在はBPMNがOMGの管理下に置かれていることから、BPMNをUMLアクティビティティ図に組み込むための作業が求められることになるだろう。それどころか、素朴なフォームを見る限りでは、BPMN/UMLアクティビティ図をラムラー・ブレーシュの図と区別することはほとんど困難で、ビジネスマンに、そのいずれかを選択すればよいと受け取られかねない。しかし、通常はもっと複雑な図で説明されることから、その2つが、いち早くビジネスマンになじみ深いものになっているのだ。こうして、ビジネスモデリングに複数の標準規格が存在することになったが、そのどちらがデファクト・スタンダードになるかは、まだ定かでない。
実施レベルのビジネスプロセス標準規格
ビジネスチームによるプロセスのリデザインが完了すると、その実施に向けた準備に、さまざまの部門が巻き込まれることになる。人事部門は、新しい業務記述書の作成、および人材の新規採用や既存人材の確保を依頼されるであろう。IT部門には、ソフトウェア開発の依頼が行く。資産管理部門は、プラントの再配置、新しいトラックの購入、物流センターの新設などを頼まれるかもしれない。
現時点では、ビジネスプロセス実施標準規格のほとんどが、IT標準規格である。それらは、2つのうちいずれかの目的の下に設定されたものだ。1つは、ITプロフェッショナルが行うビジネス要件の収集とソフトウェア・アプリケーションのデザインや手直しを支援すること。もう1つは、企業におけるプロセス情報の共通データフォーマットでの保存やソフトウェアツール間のモデル転移を、確実に可能にすることだ。
OASISのプロセス実行言語であるBPELは、最も大きな注目を集めてきた。BPELはBPMスイートと密接に連結している。しかし、幅広くとらえれば、実際にBPELを用いて開発されたBPMSアプリケーションはごくわずかであり、BPELに完全依存したアプリケーションは見当たらない。BPELの現バージョンには高度なBPMS開発を支援するには限界があり、BPELを用いるベンダは、いずれもほかのコードでそれを補完しているのだ。BPEL標準規格の進展とともに、この状況は変化するであろう。しかし、現時点におけるBPELは、まだ開発途上段階でしかない。
BPELと密接に関連するのが、ワークフロー管理連盟（WfMC）のXPDLやWorkflow Management Facilityといった標準規格である。これらの標準規格は、ワークフローシステムを支援するために開発された。最終的にはBPEL、あるいはそれに類する言語と統合し、BPMSアプリケーションの支援ツールにまでの拡充が必要になることが見込まれる。数年後には、その動きが見え始めるであろう。
OMGのUMLは、明らかにソフトウェア開発者のための表記法システムとして開発されたものだ。MDAとTOGAFはともに、BPMSにより作成されるSOAアプリケーションの構築に用いられる。また、OMGのプロダクションルール仕様が、ゆくゆくは推論ベースのシステムにビジネスルールを格納する方法の標準規格になるであろう。推論ベースのシステムは、金融機関におけるビジネスルール・システムの管理に、ますます多く用いられるようになってきた。
ザックマンのエンタープライズアーキテクチャ（EA）は、企業のIT資産目録の作成を主要業務とするエンタープライズ・アーキテクトのためのデファクト・スタンダードである。しかし、それをビジネスプロセス・アーキテクチャ標準規格と混同し、ビジネスマネジメント・ツールとして用いようとすれば、際限のない困難を引き起こす。
最後に言及するIDSシェアーの表記法かつツールであるARISは、ERPアプリケーションのダイアグラム作成のためのデファクト表記法である。SAPが図表作成に用いているのに加え、オラクルもこれを採用した。ERPフォームにおけるARISは、ソフトウェア開発者にしか理解できない表記法であり、ビジネスマネージャ用にはほかの表記法が必要なことに注意を促している。それでも、ERPベースのプロセス実装に取り組むIT開発者に広く用いられている。ただ1ついえるのは、新たに導入したERPアプリケーションのARISダイアグラムを自社のCEOに見せてはいけない、ということだ。
標準規格の今後
ここまで、プロセスマネージャと開発者に用いられている多くの標準規格のうち、ほんの一握りだけについて考察してきた。その多様性には目を見張らされる。標準規格開発の鍵を握るのは、どの部門がそれを使い、それがあることにより、どのようなアクティビティが促進されるのかの理解である。ビジネスマンにソフトウェア指向標準規格の1つを用いるよう仕向けるようなITは、通常、プロジェクトを不成功に導く。同様に、ビジネスマンが独り善がりで作成したプロセスモデルをITに押し付ける場合、それは明確さに欠けた要件と解釈されるのが普通だ。
企業がBPMSツールの活用とBPMSアプリケーションの作成の方法を追求することから、これらの問題は複雑化の一途をたどることになるだろう。
筆者が最も有望視するのは、SCOR+、VCOR、およびeTOMと称する表記法である。そして、ハイレベル・バリューチェーン表記法が企業におけるエンタープライズプロセス・アーキテクチャの創出を可能にする、という考え方に期待を持つ。このアーキテクチャが実現すれば、シニアマネージャたちが行うプロセス把握、パフォーマンス・モニタリング、およびプロセス改善課題優先度評価の容易さが増すであろう。
同時に、OMGのMDAアーキテクチャは、各標準規格の特定ユーザーグループに対する価値特性を維持しながらも、異なるレベルの標準規格相互の効果的なインターフェイスを可能にする方法を設定する能力を秘めていると思われる。
冒頭に記したように、たいていのビジネスプロセスマネージャには、標準規格に対する関心がない。しかし、時が進むにつれ、共通の約束事の使用に合意することから誰もが潤うようになるだろう。
うまくいけば、現在、標準規格に取り組んでいる大手企業とベンダが、柔軟なアーキテクチャル・システムの内部に共通の約束事を設ける道を見いだしてくれそうだ。それこそが、ビジネスプロセス業務に従事する個別部門のすべてにおいて、相互に連絡を取りながら、最も効果的と確認された方法で業務を完遂することを可能にするのである。
では、また。
ポール・ハーモン
今日のビジネスプロセス標準規格
たいていの企業のたいていの社員は、仕事の標準規格について気に掛けることがない。彼らの仕事は、それをどのように遂行するかに関する共通の理解と合意を得た多くの約束事と協定に基づき、極めて単純化されたものである。彼らは、その事実に思いをはせることなく、単に仕事をこなしているにすぎない。
- PR -
車の運転では、道路の右側を走ることと左側を走ることの間に、何の違いもない。しかし、特定地域内では、そのいずれを選択するかについて、すべての人間の合意が欠かせない。同様例で別の観点からいえば、ネジ頭の形状数を限定し、2セットのドライバーでほとんどの場合に対応できることで、われわれ全員が恩恵を被っているのである。
筆者（ポール・ハーモン）は、ほかのアドバイザリ・Webページ※1で、ジェフリー・ムーアの技術導入ライフサイクルモデルについて論じたことがある（図1）。
※1 訳注：本稿を含め、筆者が月次発信するBPM論考シリーズ
簡潔にいえば、イノベーターの範疇（はんちゅう）に属する企業は大学や研究機関から直接新しい技術を採用し、それを大きな競争力の源泉となる突破口として活かそうとする。その技術を役立てる方法を見いだすために、膨大なリソースを積極的に投じている。早期導入者は少し遅れて技術を採用し、競合企業より先に用途を開発することで競争優位に立とうとする。
早期多数派に位置する企業は、新技術を導入する前に、その技術の有効性が明らかになるまで待つ。それにより、新技術の実験と未成熟なツールとの格闘に必要なコスト高の努力を回避する。さらに注目されるのは、彼らが標準規格が整うまで待とうとすることだ。別のいい方をすれば、少なくとも技術領域における標準規格開発は、技術ライフサイクルの早期導入者フェイズの期間中にベンダと先行的ユーザーによって遂行される活動なのである。
図1 ジェフリー・ムーアの技術導入ライフサイクル
標準規格開発への取り組みに関心を持つ企業は、そう多くない。たいていの企業は、技術の普及体制が整うころには標準規格も完成しているはず、と見込んでいるのだ。数年内に有効な標準規格が作成できなかったために、キャズム※2に落ち込み消え去る技術もある。
※2 編注：リリースできなかったとすれば、死の谷というべきかもしれない
標準規格について考えるときに念頭に置かなければならないもう1つの事柄は、デファクト・スタンダードとデジュアリ・スタンダードの違いである。デジュアリ（公的な）・スタンダードは、標準規格機関や業界コンソーシアムによって設定される。片や公式的取り決めを求めないコミュニティによって定められるのが、デファクト（実際上の）・スタンダードだ。
例えばMicrosoft Windowsは、90％以上のPCユーザーが依存するマイクロソフトのOSである。それはOSのデファクト・スタンダードであり、PC用ソフトウェアを売ろうとするベンダであれば、それを支持せざるを得ないであろう。
複雑で急速に進展する環境下では、デファクト・スタンダードの方が、デジュアリ・スタンダードよりも重要である場合が多い。デジュアリ・スタンダードの決定には、通常、より長い時間がかかるからだ。別のいい方をすれば、有力なベンダが一般の標準規格に従えない場合に裁定を下すのは市場であり、結局はデジュアリ・スタンダードとなるベンダが勝利を収めるのである。
これらの考察を念頭に置き、今日のビジネスプロセスに関する標準規格について少し述べたい。この論述の整理の仕方として、標準規格を利用する立場に応じ、それらを3つの大きな枠組みに分類してゆくことになろう。
まず、エンタープライズレベル標準規格は、ビジネスマネージャが、事業活動を分析し体系化するために使用する。
プロセスレベル標準規格は、ビジネスマネージャとビジネスプロセス担当者が、ビジネスプロセス変革プロジェクトの実施に臨む際に使用する。ビジネス・プロジェクトの実施には多様な立場の個人が携わるため、この領域の取りまとめが最も難しい。ある場合には、ビジネスマネージャがビジネス改革プロジェクトの実施に当たる。一方、ITビジネス・アナリストその他のIT関係者がプロセス自動化プロジェクトを遂行するといった実態がある。
実施レベル標準規格は、プロセスにかかわる問題のソリューション開発担当者によって使用される技術を特定対象とするものだ。この領域の標準規格の大半は、ソフトウェア開発の方法あるいはソフトウェア・ツールのインターフェイスの方法を定めたIT標準規格である。既存の、あるいは現在開発途上にあるビジネスプロセス標準規格のすべてを包含するのはほとんど不可能なことだが、大局的見地からの概観は持ちたい。
いうまでもなく、筆者はこの論述の構成と標準規格の分類を筆者自身の経験に照らして行った。これらの標準規格を、筆者と異なる様式で整理される方もおられるに違いない。また、筆者の考えで分類した標準規格の中には、ほかの範疇に位置付けてもよいものもあるだろう。いずれにせよ、概観を簡潔に提示することが必要なのだ。
エンタープライズレベル・ビジネスプロセス標準規格
エンタープライズレベル・ビジネスプロセス標準規格は、ビジネス・パフォーマンスの概要把握、評価、およびマネジメントの体系化を支援するツールとして、エグゼクティブとシニア・ビジネスマネージャに使用される。さらに、エグゼクティブ・コミッティ傘下にBPMグループを設置し、同標準規格をマネージャのパフォーマンス評価とプロセス介入優先順位設定のツールとして用いている企業もある。
恐らく、エンタープライズレベルで最も広く用いられているビジネスプロセス標準規格は、キャプランとノートンのバランスト・スコアカード（BSC）による経営評価アプローチであろう。これは事実上のデファクト・スタンダードであり、多様な様式で用いられていると思われる。しかし、多様ではあっても、キャプランとノートンのアプローチの改変版の間には十分な共通項が見られる。もしバランスト・スコアカードを用いているかと問われた場合、たいていの企業は直ちに「イエス」か「ノー」の回答ができるはずだ。
エンタープライズレベルにおいて、最も注目されるビジネスプロセス標準規格が、サプライチェーン・カウンシルのSCORフレームワークと方法論である。SCORは、複数企業にまたがるサプライチェーン・プロセスを構築し評価するためのツールとして、サプライチェーン・マネージャたちによって開発された。バリューチェーン全体の定義、ベンチマーキング、および評価を行うための標準規格として、急速に普及している。その増幅版では、SCOR+とSCOR/DCOR/CCOR（サプライチェーン・モデル、デザインチェーン・モデル、カスタマーチェーン・モデルに対応）の、いずれかの名称が使用されるようになった。
今後数年間には、プロセスセントリック・アプローチを導入するシニア・エグゼクティブが増加する。これに伴い、SCOR+の重要度も増すに違いない。
VCORは、SCOR+と非常に類似点が多いが、もう1つの異なるアプローチだ。eTOMは、テレコム業界向けに特別に作成されたフレームワークである（今後は、ほかの業界でも、同様のフレームワークが作成される可能性が大きい）。
エンタープライズレベルで時々用いられる、もう1つの標準規格が、ソフトウェアエンジニアリング・インスティチュート（SEI）のケイパビリティ成熟度統合モデル（CMMI）である。CMMIをITプロセスのパフォーマンス評価に用いているケースが圧倒的に多く、この場合には、CMMIをプロセスレベル標準規格と位置付けるのが妥当であろう。しかし、一部の企業では、すべてのビジネスプロセスを評価し全体組織の動向を見極めるために用いられている。この場合には、エンタープライズレベルのツールとして機能していると見てよい。
さまざまな米国政府機関の支柱になっているのが、連邦エンタープライズアーキテクチャ・フレームワーク（FEAF）だ。FEAFは、ある意味ではエンタープライズ・ツールであり、いくつかの機関がその位置付けで用いている。しかし、ITアーキテクチャ構築のアプローチとして用いられることがほとんどで、この場合には、ザックマンのようなIT実行標準規格の範疇に含められるであろう。
図2に、筆者が想定する主要なビジネスプロセス標準規格の位置付けを示しておく。
プロセスレベルは、全体がプロセスのリデザイン／実施プロジェクトの集積である。このレベルの標準規格は、具体的なプロセスの改革に当たるマネージャ、従業員、ビジネスアナリスト、およびヒューマンパフォーマンス・アナリストを支援する。
これまでに、プロセスレベルで最も広く用いられてきた標準規格は、シックスシグマであった。企業や標準規格機関ごとに多様に定義されてきた、もう1つのデファクト・スタンダードでもある。しかし、たいていのシックスシグマ改変版の間には、容易に認識できる、ファミリとしての類似性がある。シックスシグマは、汎用的プロセス改善手法（DMAIC）と、プロセス改善チームがプロセスの改善に適用できる多彩なツールを備えているのだ。
リーンはプロセスフローの無駄の除去に重点化した別個の手法であり、一般的に、シックスシグマ・チームが取り込むべきツールの1つだと考えられている。従って、恐らく、この標準規格は「シックスシグマ／リーン」と称されるべきなのだろう。
いずれにせよ、多くの大手企業が膨大な数の従業員に対してシックスシグマ教育を行い、シックスシグマ／リーン・アプローチにのっとった数多くの改善プロジェクトを定期的に実施しているのである。
シックスシグマとほぼ同等に普及しているのが、ISO 9000だ（この標準規格は9000番台に関し、多くのバリエーションを持つが、一般的にはこの呼称で通っている）。突き詰めれば、ISO 9000は国際標準規格機構が定めたビジネスプロセス定義の仕様である。ヨーロッパの多くの大手企業と政府が、ISO 9000を用いてプロセスを定義することを企業に義務付けている。
残念なことに、この標準規格は、いまや「チェックリスト」項目でしかなくなってしまった。ISO 9000の文書を手早く作成し、それを棚さらしにしている企業がほとんどだ。今日のビジネスプロセス業務に合わせてISO 9000の意義を高めようとする動きはある。しかし、現状では、企業におけるプロセスの実際的運用に対するISO文書のインパクトは、ほとんど見られない。
米国では、たいていの企業がサーベンス・オクスリー法（SOX法）に対応するための文書作成に取り組んできた。重要な財務上の意思決定に結び付くプロセスを追跡できる体制が整っていることを示すよう、企業に義務付けた米国内法である。ISO 9000と同じく、サーベンス・オクスリー法は、社内プロセスの把握を大きく前進させる機会を企業に与える。しかし、やはり、あまりにも短時間内に処理されてきたのがサーベンス・オクスリーの実態だ。やがて棚の上でISO 9000関連文書のそばで眠る貯蔵品になってしまう可能性が極めて大きい。
最近、OMGがルールの標準規格（および、それに関連するビジネスモチベーション・モデル）を公開した。元はビジネスルールズ・コミュニティ（BRC）で開発されたものだが、企業で用いる語彙、方針、ビジネスルールを定義するための標準規格を定めている。この領域では金融機関の取り組みが非常に活発であり、この標準が、やがて金融機関におけるオントロジーとビジネスルールを確立するためのてことして活かされるであろう。
特定の業界あるいは領域に特化した、いくつかのビジネス・フレームワークは、プロセスチームが既存ビジネスプロセスのデザインと評価を行うのに役立つ。ITIL（ITサポート・プロセスの標準規格）とCoBiT（ITマネジメント・プロセスの標準規格）は、その好例だ。双方に対し、ITプロセスの全社的標準化を望む企業からの関心が高まっている。
この数年、ビジネスプロセス・モデラーが多種多様なワークフロー表記法を用いてきた。その代表例が、IDEF0とラムラー・ブレーシュである。普及度の高いプロセスモデリング・ツールのほとんどが、これらの2つの表記法を支持し、その自社版を提供している。
しかし、いまのところ、ビジネスマンの大多数がよりどころとするデファクト・スタンダードはない。フロー図によるビジネスプロセスの文書化と、遂行すべきタスクを記述した図の読み方に関する社員教育を行っている企業が多いという考察に至れば、標準的ビジネスプロセス表記法に有用性を見いだすことになるだろう。
現時点で最も推奨できるのが、BPMI/OMGのビジネスプロセスマネジメント表記法（BPMN）だ。大手プロセスモデリング・ベンダが結成したチームにより開発されたという点、および、コア・バージョンでビジネスマンが必要とする基本的表記法を提供している点で評価できる。半面、ビジネスプロセス実行言語（BPEL）を作成する機能まで持たせたために、明らかにビジネスマンには必要のない、あるいは理解できない多くの表記法が含まれている点はいただけない。
さらに、現在はBPMNがOMGの管理下に置かれていることから、BPMNをUMLアクティビティティ図に組み込むための作業が求められることになるだろう。それどころか、素朴なフォームを見る限りでは、BPMN/UMLアクティビティ図をラムラー・ブレーシュの図と区別することはほとんど困難で、ビジネスマンに、そのいずれかを選択すればよいと受け取られかねない。しかし、通常はもっと複雑な図で説明されることから、その2つが、いち早くビジネスマンになじみ深いものになっているのだ。こうして、ビジネスモデリングに複数の標準規格が存在することになったが、そのどちらがデファクト・スタンダードになるかは、まだ定かでない。
実施レベルのビジネスプロセス標準規格
ビジネスチームによるプロセスのリデザインが完了すると、その実施に向けた準備に、さまざまの部門が巻き込まれることになる。人事部門は、新しい業務記述書の作成、および人材の新規採用や既存人材の確保を依頼されるであろう。IT部門には、ソフトウェア開発の依頼が行く。資産管理部門は、プラントの再配置、新しいトラックの購入、物流センターの新設などを頼まれるかもしれない。
現時点では、ビジネスプロセス実施標準規格のほとんどが、IT標準規格である。それらは、2つのうちいずれかの目的の下に設定されたものだ。1つは、ITプロフェッショナルが行うビジネス要件の収集とソフトウェア・アプリケーションのデザインや手直しを支援すること。もう1つは、企業におけるプロセス情報の共通データフォーマットでの保存やソフトウェアツール間のモデル転移を、確実に可能にすることだ。
OASISのプロセス実行言語であるBPELは、最も大きな注目を集めてきた。BPELはBPMスイートと密接に連結している。しかし、幅広くとらえれば、実際にBPELを用いて開発されたBPMSアプリケーションはごくわずかであり、BPELに完全依存したアプリケーションは見当たらない。BPELの現バージョンには高度なBPMS開発を支援するには限界があり、BPELを用いるベンダは、いずれもほかのコードでそれを補完しているのだ。BPEL標準規格の進展とともに、この状況は変化するであろう。しかし、現時点におけるBPELは、まだ開発途上段階でしかない。
BPELと密接に関連するのが、ワークフロー管理連盟（WfMC）のXPDLやWorkflow Management Facilityといった標準規格である。これらの標準規格は、ワークフローシステムを支援するために開発された。最終的にはBPEL、あるいはそれに類する言語と統合し、BPMSアプリケーションの支援ツールにまでの拡充が必要になることが見込まれる。数年後には、その動きが見え始めるであろう。
OMGのUMLは、明らかにソフトウェア開発者のための表記法システムとして開発されたものだ。MDAとTOGAFはともに、BPMSにより作成されるSOAアプリケーションの構築に用いられる。また、OMGのプロダクションルール仕様が、ゆくゆくは推論ベースのシステムにビジネスルールを格納する方法の標準規格になるであろう。推論ベースのシステムは、金融機関におけるビジネスルール・システムの管理に、ますます多く用いられるようになってきた。
ザックマンのエンタープライズアーキテクチャ（EA）は、企業のIT資産目録の作成を主要業務とするエンタープライズ・アーキテクトのためのデファクト・スタンダードである。しかし、それをビジネスプロセス・アーキテクチャ標準規格と混同し、ビジネスマネジメント・ツールとして用いようとすれば、際限のない困難を引き起こす。
最後に言及するIDSシェアーの表記法かつツールであるARISは、ERPアプリケーションのダイアグラム作成のためのデファクト表記法である。SAPが図表作成に用いているのに加え、オラクルもこれを採用した。ERPフォームにおけるARISは、ソフトウェア開発者にしか理解できない表記法であり、ビジネスマネージャ用にはほかの表記法が必要なことに注意を促している。それでも、ERPベースのプロセス実装に取り組むIT開発者に広く用いられている。ただ1ついえるのは、新たに導入したERPアプリケーションのARISダイアグラムを自社のCEOに見せてはいけない、ということだ。
標準規格の今後
ここまで、プロセスマネージャと開発者に用いられている多くの標準規格のうち、ほんの一握りだけについて考察してきた。その多様性には目を見張らされる。標準規格開発の鍵を握るのは、どの部門がそれを使い、それがあることにより、どのようなアクティビティが促進されるのかの理解である。ビジネスマンにソフトウェア指向標準規格の1つを用いるよう仕向けるようなITは、通常、プロジェクトを不成功に導く。同様に、ビジネスマンが独り善がりで作成したプロセスモデルをITに押し付ける場合、それは明確さに欠けた要件と解釈されるのが普通だ。
企業がBPMSツールの活用とBPMSアプリケーションの作成の方法を追求することから、これらの問題は複雑化の一途をたどることになるだろう。
筆者が最も有望視するのは、SCOR+、VCOR、およびeTOMと称する表記法である。そして、ハイレベル・バリューチェーン表記法が企業におけるエンタープライズプロセス・アーキテクチャの創出を可能にする、という考え方に期待を持つ。このアーキテクチャが実現すれば、シニアマネージャたちが行うプロセス把握、パフォーマンス・モニタリング、およびプロセス改善課題優先度評価の容易さが増すであろう。
同時に、OMGのMDAアーキテクチャは、各標準規格の特定ユーザーグループに対する価値特性を維持しながらも、異なるレベルの標準規格相互の効果的なインターフェイスを可能にする方法を設定する能力を秘めていると思われる。
冒頭に記したように、たいていのビジネスプロセスマネージャには、標準規格に対する関心がない。しかし、時が進むにつれ、共通の約束事の使用に合意することから誰もが潤うようになるだろう。
うまくいけば、現在、標準規格に取り組んでいる大手企業とベンダが、柔軟なアーキテクチャル・システムの内部に共通の約束事を設ける道を見いだしてくれそうだ。それこそが、ビジネスプロセス業務に従事する個別部門のすべてにおいて、相互に連絡を取りながら、最も効果的と確認された方法で業務を完遂することを可能にするのである。
では、また。
ポール・ハーモン
PR
アイログ▼最適化製品のILOG ODMが「Powered by SAP NetWeaver認定」を取得
アイログの業界特化型ソリューションのILOG PPOとTPO、
最適化製品のILOG ODMが「Powered by SAP NetWeaver認定」を取得
SAPソリューションのユーザに最先端の最適化技術導入への道を開くアイログのソリューション
ビジネス・ルール管理、最適化、可視化技術で企業の迅速な意思決定を支援するアイログ社（NASDAQ：ILOG； Euronext： ILO、ISIN： FR0004042364）は本日、サプライチェーン向けプランニング製品およびスケジューリング製品のうち、3製品が「Powered by SAP NetWeaver(R)」の認定を受けたと発表しました。今回SAP(R) Integration and Certification Centerが認定したアプリケーションは、ILOG(R) Plant PowerOps (PPO)、ILOG TransportPowerOps (TPO)、ILOG Optimization Decision Manager(ODM) の3製品で、これらがSAP NetWeaver プラットフォームのSAP NetWeaverExchangeInfrastructure (SAP NetWeaver XI) コンポーネントに正しく統合されることでSAP Business Suite製品群の各ソリューションの様々なインスタンスとの間で重要データの交換が可能であるとともに、SAP NetWeaver Portalへも適切に統合できることが認定されました。
ILOG PPOは、中間製品と最終製品それぞれの生産スケジュールを統合することが求められている加工生産を行う工場が対象です。一方ILOG TPOは物流サービスの委託を請け負う3PL事業者や配送請負企業が対象で、これらの企業では借り受けたり自社で保有する運送手段を始め、クロスドック、帰り荷などの運用を最適化することが求められています。3番めのILOG ODMは、既存のパッケージ・アプリケーションでは不可能な企業独自のプランニング/スケジューリング問題の解決を目指す場合に利用するツールであり、インタラクティブな意思決定支援アプリケーションの自社開発が可能になります。
先ごろアイログが買収し、現在はアイログの一事業部であるLogicToolsが提供するサプライチェーン・プランニング向けアプリケーションでは、サプライチェーン・ネットワークの設計とマルチ・エシュロン（多段階）在庫の最適化を行うことができます。アイログのサプライチェーン向けスケジューリング製品やカスタマイズ・ソリューションは、これらのLogicTools製品群を補完します。
なお、LogicToolsのInventory Analyst(TM)とSafety Stock OptimizerというソリューションはすでにSAP との統合が認定済みです。
これらのアイログ製品が「Powered by SAP NetWeaver」の認定を受けたことは、SAPソリューションを業務に利用しているユーザにとって、アイログの最適化技術を基盤とするアプリケーションをより簡単に組み込めるようになりました。たとえば、SAPソリューションを基盤としたシステム環境で受注管理活動を行っている生産計画担当者であれば、現在の業務環境を維持しながら、ILOG Plant PowerOpsを利用して生産計画と詳細スケジューリングができるようになりました。同様にして、自社開発のプランニング・アプリケーションをSAP NetWeaver Portalから起動することもできます。
ユーザはアイログの最適化技術を基盤とするソリューションをSAPの各アプリケーションと連携して利用できるため、データ・ソースの複数化を避けてマスター・データとトランザクション・データの整合性を守りつつ、アイログ製品が備える最先端の最適化機能を存分に活用できます。
SAP NetWeaverプラットフォームは、SAP Business Suite製品群の各アプリケーションや、コンポジット・アプリケーションのパッケージであるSAP xApps(TM)、さらにアイログのILOG Plant PowerOps、ILOG TransportPowerOps、ILOG Optimization Decision Managerなどのソリューションの基盤となっています。SAP NetWeaverは様々な統合技術を単一プラットフォーム化したもので、各種の業務アプリケーションにあらかじめ統合されていることで、変更を可能にし特別な統合作業を行う必要性を少なくしています。
グローバル500社のうちの150社以上を含む、1,000社を超える企業がアイログのサプライチェーン向けプランニング/スケジューリング・アプリケーションとアイログの最適化ツール/エンジンを利用して、最も難しいとされるプランニングやスケジューリングの問題を解決しています。
アイログ社（ILOG(R)）について
アイログ社は、お客様がより迅速な意思決定を行い、変更および複雑度を管理するためのソフトウェアおよびサービスを提供しています。全世界で2,500社を超える企業や465社を超えるソフトウェア・ベンダが、市場をリードするアイログのBRMS（ビジネス・ルール管理システム）、サプライチェーン向けプランニングならびにスケジューリング・アプリケーション、最適化ならびに可視化のソフトウェア・コンポーネントの活用により飛躍的な投資効率を達成し、市場を席巻する製品やサービスを立ち上げ、また、その競争力を強めています。アイログ社は1987年に設立され、全世界に800名以上の社員を有しています。アイログ株式会社はアイログ社の日本法人です。
詳細についてはwww.ilog.co.jpをご覧ください。
*ILOG は ILOG S.A.とILOG Inc.の登録商標です。ILOG Plant PowerOps,Transport PowerOps, Optimization Decision Manager, Inventory AnalystはILOG S.A.とILOG Inc.の商標です。当リリース内に言及されているSAP、SAP NetWeaver、xAppsまた他のSAP製品とサービスならびにそれぞれのロゴは、ドイツとその他の国でSAP AGの商標または登録商標です。
他の全ての社名および商品名はそれぞれを所有する各社の商標または登録商標です。
以上
●この件についてのお問い合わせ先
アイログ株式会社
マーケティング＆アライアンス マネージャー ジョエル ゲイ
マーケティング・スペシャリスト 豊原 正也
〒102-0075 東京都千代田区三番町24-14 YS三番町ビル３F
TEL：03-5211-5770 FAX： 03-5211-5771 Email： mktg@ilog.co.jp
アイログの業界特化型ソリューションのILOG PPOとTPO、
最適化製品のILOG ODMが「Powered by SAP NetWeaver認定」を取得
SAPソリューションのユーザに最先端の最適化技術導入への道を開くアイログのソリューション
ビジネス・ルール管理、最適化、可視化技術で企業の迅速な意思決定を支援するアイログ社（NASDAQ：ILOG； Euronext： ILO、ISIN： FR0004042364）は本日、サプライチェーン向けプランニング製品およびスケジューリング製品のうち、3製品が「Powered by SAP NetWeaver(R)」の認定を受けたと発表しました。今回SAP(R) Integration and Certification Centerが認定したアプリケーションは、ILOG(R) Plant PowerOps (PPO)、ILOG TransportPowerOps (TPO)、ILOG Optimization Decision Manager(ODM) の3製品で、これらがSAP NetWeaver プラットフォームのSAP NetWeaverExchangeInfrastructure (SAP NetWeaver XI) コンポーネントに正しく統合されることでSAP Business Suite製品群の各ソリューションの様々なインスタンスとの間で重要データの交換が可能であるとともに、SAP NetWeaver Portalへも適切に統合できることが認定されました。
ILOG PPOは、中間製品と最終製品それぞれの生産スケジュールを統合することが求められている加工生産を行う工場が対象です。一方ILOG TPOは物流サービスの委託を請け負う3PL事業者や配送請負企業が対象で、これらの企業では借り受けたり自社で保有する運送手段を始め、クロスドック、帰り荷などの運用を最適化することが求められています。3番めのILOG ODMは、既存のパッケージ・アプリケーションでは不可能な企業独自のプランニング/スケジューリング問題の解決を目指す場合に利用するツールであり、インタラクティブな意思決定支援アプリケーションの自社開発が可能になります。
先ごろアイログが買収し、現在はアイログの一事業部であるLogicToolsが提供するサプライチェーン・プランニング向けアプリケーションでは、サプライチェーン・ネットワークの設計とマルチ・エシュロン（多段階）在庫の最適化を行うことができます。アイログのサプライチェーン向けスケジューリング製品やカスタマイズ・ソリューションは、これらのLogicTools製品群を補完します。
なお、LogicToolsのInventory Analyst(TM)とSafety Stock OptimizerというソリューションはすでにSAP との統合が認定済みです。
これらのアイログ製品が「Powered by SAP NetWeaver」の認定を受けたことは、SAPソリューションを業務に利用しているユーザにとって、アイログの最適化技術を基盤とするアプリケーションをより簡単に組み込めるようになりました。たとえば、SAPソリューションを基盤としたシステム環境で受注管理活動を行っている生産計画担当者であれば、現在の業務環境を維持しながら、ILOG Plant PowerOpsを利用して生産計画と詳細スケジューリングができるようになりました。同様にして、自社開発のプランニング・アプリケーションをSAP NetWeaver Portalから起動することもできます。
ユーザはアイログの最適化技術を基盤とするソリューションをSAPの各アプリケーションと連携して利用できるため、データ・ソースの複数化を避けてマスター・データとトランザクション・データの整合性を守りつつ、アイログ製品が備える最先端の最適化機能を存分に活用できます。
SAP NetWeaverプラットフォームは、SAP Business Suite製品群の各アプリケーションや、コンポジット・アプリケーションのパッケージであるSAP xApps(TM)、さらにアイログのILOG Plant PowerOps、ILOG TransportPowerOps、ILOG Optimization Decision Managerなどのソリューションの基盤となっています。SAP NetWeaverは様々な統合技術を単一プラットフォーム化したもので、各種の業務アプリケーションにあらかじめ統合されていることで、変更を可能にし特別な統合作業を行う必要性を少なくしています。
グローバル500社のうちの150社以上を含む、1,000社を超える企業がアイログのサプライチェーン向けプランニング/スケジューリング・アプリケーションとアイログの最適化ツール/エンジンを利用して、最も難しいとされるプランニングやスケジューリングの問題を解決しています。
アイログ社（ILOG(R)）について
アイログ社は、お客様がより迅速な意思決定を行い、変更および複雑度を管理するためのソフトウェアおよびサービスを提供しています。全世界で2,500社を超える企業や465社を超えるソフトウェア・ベンダが、市場をリードするアイログのBRMS（ビジネス・ルール管理システム）、サプライチェーン向けプランニングならびにスケジューリング・アプリケーション、最適化ならびに可視化のソフトウェア・コンポーネントの活用により飛躍的な投資効率を達成し、市場を席巻する製品やサービスを立ち上げ、また、その競争力を強めています。アイログ社は1987年に設立され、全世界に800名以上の社員を有しています。アイログ株式会社はアイログ社の日本法人です。
詳細についてはwww.ilog.co.jpをご覧ください。
*ILOG は ILOG S.A.とILOG Inc.の登録商標です。ILOG Plant PowerOps,Transport PowerOps, Optimization Decision Manager, Inventory AnalystはILOG S.A.とILOG Inc.の商標です。当リリース内に言及されているSAP、SAP NetWeaver、xAppsまた他のSAP製品とサービスならびにそれぞれのロゴは、ドイツとその他の国でSAP AGの商標または登録商標です。
他の全ての社名および商品名はそれぞれを所有する各社の商標または登録商標です。
以上
●この件についてのお問い合わせ先
アイログ株式会社
マーケティング＆アライアンス マネージャー ジョエル ゲイ
マーケティング・スペシャリスト 豊原 正也
〒102-0075 東京都千代田区三番町24-14 YS三番町ビル３F
TEL：03-5211-5770 FAX： 03-5211-5771 Email： mktg@ilog.co.jp
KDDI研究所、携帯電話を使った農作物生産管理・情報公開システムの実証実験
KDDI研究所（秋葉重幸所長）は5月29日、農業分野でのICT（情報・通信技術）ニーズに対応するため、「携帯電話による農産物生産管理サービスと専用ブログによる生産情報公開サービス」を提供するシステムを開発し、同システムを活用した実証実験を栃木県立宇都宮白楊高等学校（柴田富男学校長）と共同で5月初旬から開始したと発表した。
同システムは、三菱電機エンジニアリングの「e農業日誌Webサービス」と、KDDI研究所が試作した「携帯電話版ライフログ」を組み合わせたもの。「e農業日誌Webサービス」は、簡単に作業計画、作業履歴の入力ができ、情報公開用のホームページが作成できるサービス。しかし、PCの利用を前提としているため、生産者が作業場所で作業計画の確認や作業記録を作成するためには、紙での記録などが必要だった。
今回、KDDI研究所は「e農業日誌Webサービス」と、GPS、カメラなど携帯電話に搭載された機能から取得した情報を自宅のPC上で簡単にブログ化するサービス「携帯電話版ライフログ」と組み合わせることで、「農産物生産管理機能」と「生産情報公開機能」の2つの機能を持つ携帯電話アプリケーションを開発した。
「農産物生産管理機能」では、携帯電話で位置情報、日時、使用する農薬・肥料情報のいずれかの情報を取得するだけで、作業計画の確認や作業記録を残せる。「生産情報公開機能」は、この作業記録をもとに成育日記（ブログ）を作成し、公開することができる。
同システムは、携帯電話を利用するため簡単に導入できる上、農業の生産現場でGAP（適正農業規範）に適合した作業の徹底管理が可能となる。これにより、消費者は安全で信頼性のある農産物の供給を受けることができ、ブログを使って農業生産者とコミュニケーションを図ることもできる。今後、実証実験での評価を参考に商用化を検討していく。
なお、KDDI研究所が開発した技術は、総務省から受託した「ユビキタスネットワーク制御・管理技術の研究開発」の成果を応用したもので、RFID（電子タグ）を用いた生産管理にも対応できるという。
KDDI研究所＝http://www.kddilabs.jp/
三菱電機エンジニアリング＝http://www.mee.co.jp/
栃木県立宇都宮白楊高等学校＝http://www.utsunomiyahakuyo-h.ed.jp/
「e農業日誌Webサービス」＝http://www.mee.co.jp/sales/other/e-nougyou/
KDDI研究所（秋葉重幸所長）は5月29日、農業分野でのICT（情報・通信技術）ニーズに対応するため、「携帯電話による農産物生産管理サービスと専用ブログによる生産情報公開サービス」を提供するシステムを開発し、同システムを活用した実証実験を栃木県立宇都宮白楊高等学校（柴田富男学校長）と共同で5月初旬から開始したと発表した。
同システムは、三菱電機エンジニアリングの「e農業日誌Webサービス」と、KDDI研究所が試作した「携帯電話版ライフログ」を組み合わせたもの。「e農業日誌Webサービス」は、簡単に作業計画、作業履歴の入力ができ、情報公開用のホームページが作成できるサービス。しかし、PCの利用を前提としているため、生産者が作業場所で作業計画の確認や作業記録を作成するためには、紙での記録などが必要だった。
今回、KDDI研究所は「e農業日誌Webサービス」と、GPS、カメラなど携帯電話に搭載された機能から取得した情報を自宅のPC上で簡単にブログ化するサービス「携帯電話版ライフログ」と組み合わせることで、「農産物生産管理機能」と「生産情報公開機能」の2つの機能を持つ携帯電話アプリケーションを開発した。
「農産物生産管理機能」では、携帯電話で位置情報、日時、使用する農薬・肥料情報のいずれかの情報を取得するだけで、作業計画の確認や作業記録を残せる。「生産情報公開機能」は、この作業記録をもとに成育日記（ブログ）を作成し、公開することができる。
同システムは、携帯電話を利用するため簡単に導入できる上、農業の生産現場でGAP（適正農業規範）に適合した作業の徹底管理が可能となる。これにより、消費者は安全で信頼性のある農産物の供給を受けることができ、ブログを使って農業生産者とコミュニケーションを図ることもできる。今後、実証実験での評価を参考に商用化を検討していく。
なお、KDDI研究所が開発した技術は、総務省から受託した「ユビキタスネットワーク制御・管理技術の研究開発」の成果を応用したもので、RFID（電子タグ）を用いた生産管理にも対応できるという。
KDDI研究所＝http://www.kddilabs.jp/
三菱電機エンジニアリング＝http://www.mee.co.jp/
栃木県立宇都宮白楊高等学校＝http://www.utsunomiyahakuyo-h.ed.jp/
「e農業日誌Webサービス」＝http://www.mee.co.jp/sales/other/e-nougyou/
