＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ユーザ目線のシステム作り：SOA（BPM＋Web2.0）
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-01-03 23:30
先に書きますが、断定調で書きますが、必ずしも断定していません。 で、ですが。 まず前提。 (1)「業務」とはデータが「がちがち」になってから行うものを言います。それ以外は単なる試行です。顧客は「業務」をしたいのであって、「試行」をしたいとは思いません。 (2)問題は「業務」になってから発生します。「試行」時には問題は発生しません。問題が発生しないということは、開発する必要も存在しないことを指しています。ただ通り抜けるだけのシステムなど開発する理由が無いことは明らかです。
通常、「業務」はERP上で行います。それ以外のCMSやBPMS上で行うのは、その場合は単なる「試行」のように見えます。というのも。
これは明らかに「業務」ではありませんし
こっちが「業務」なのかは微妙です。なんともいいようがありません。 データ生成に必要なら単なる業務ですし、データ生成に不要なら、単に不要な処理です。
それは単に作る人がわかってないから、というだけなのでは。ちゃんとデータの設計を行えば「試行」する必要がありません。
残念ながら、ここでデータが確定したなら、ERPに流れるしかないと思います。 正確に言えば、BPMSがまったく不要です。なぜなら上記の意味の「トランザクションデータ」は業務に不要ならいらないし(「試行」レベル)「トランザクションデータ」が必要なら、それはERPに流さざる得ないからです。
BPMSの場所で問題が発生しない以上(「試行」しているだけなら、誰も本気でデータ整備しようと思わないから)結局はERPに手を入れて業務を実装するだけになると思います。 で、それであるならCMSは、たんなる「だべり」と一緒であり、やるだけ無駄です。 というか、CMS→BPMS→ERPとして、連携させる必要がありません。各独立にシステムを作ってすり合わせたほうがましです。 ということで、標準化を考慮しない大多数のシステムと同様、各システム「だけ」に有用な方法に見えます。 あるシステムで、その「BPWeb 2.0」とやらが良さそうに見えることは否定しませんが。 さらにいうなら、その「BPWeb 2.0」とやらは、システムの可動範囲、なんといえばいいのか、仕様を変更できる範囲をCMSや、BPMSに移しただけのように見えます。 結局は、一番重要な「どこを」仕様を柔軟にするかという問題をCMS、BPMSという単語に 仮託しているように見えます。それはシステム設計の一部。で重要だったり重要じゃなかったりする一部だと思います。 ということで、本質的なところは変わらないような気がしますが。。。 | ||||||||||||||||||||||||||||
|
投稿日時: 2008-01-04 02:50
markさん、２００８年になりましたね、年賀状代わりですが今年も宜しく。
いよいよ開始ですね、第一投有り難うございます。楽しくやっていきましょう。 三層アプリケーションプラットフォームですね。 突然で解らない方もと思い、konibi的（私的）に少し解説をします。 その昔OSI７層では、アプリケーション層は第七層とされていましたが、それから四半世紀が経ち、そのアプリケーション層の議論が面白くなってきました。そこを更に三層に分割しようというのが、三層アプリケーションプラットフォームの基本的考えです。 三層に分割する前に二層に分割する話をします。 基幹業務（ERP・CRM・レガシー）をEAI（最近はESBですね、SAPはBPPと云ってますが）で連携させて業務連携をしようとゆうのはよろしいでしょうか。これを最近ではSOAでお色直しさせてまたPRしてますね。WorkFlow系BPMSは、その上位に位置し、基幹との連携（BPMSは既存のアプリを変更せずに連携可能）を行います、つまり基幹業務--（EAI）--BPMSという図です。 これはmark的に表現すると二層アプリケーション（EAIは、つなぎ役です）となるわけです。三層はBPMSの更に上に（更にユーザ側に）CMSが来るというわけです。 つまり基幹業務--（EAI）--BPMS--CMSとなるわけです。 そのメリット等は、これからの興味ある議論となるでしょう。 三層アプリケーションプラットフォームはソフト開発手法を云っているわけですが、決してそれだけでは無いようです。先回書いた産業構造云々は今後にしますが、人間の組織構造（会社がその典型）から見てもピタリの様です。先日、東大の松島克守さんがPLM（Product Lifecycle Management）で云ってました。三層モデル（経営戦略--実行計画管理--オペレーション）の最適化を実現するのがITだと。 [ メッセージ編集済み 編集者: konibi 編集日時 2008-01-04 02:58 ] | ||||||||||||||||||||||||||||
|
投稿日時: 2008-01-04 09:21
冬休みも終わってしまうのでここまででの私の感想を書いておきます。
(今後も時間があったら覗いてみます) まず
これが絵に描いた餅というのが現状のような気がします。 ユーザ(オペレータ)のみの手によってデータの確定をしようとしても おそらく必要なデータ構造を決めるまでに数年かかってしまうのでは？ またもっと根本的なことですが
私の解釈では 「三層アプリケーションプラットフォーム」はシステムの構造 そのものであり 「ソフト開発手法」はシステムを構築していく方法論 です。 システム構造が方法論の一要素になるかもしれませんが 両者が同一のものではないと思っています。 | ||||||||||||||||||||||||||||
|
投稿日時: 2008-01-04 16:31
るぱんです。
あらかた加納さんが書いてるのですが・・・。 僕なりにわからない点を書いてみました。 １点目。 データのつなぎ目を誰がメンテナンスするの？ ユーザーにやらせるの？ ベンダーに責任が落ちてこない点では大賛成。 具体的に例を出すと、BPMS上、別バージョン同じBPMがあったとして、 稼動時期的な不整合は誰がどのように吸収しますか？ （もちろんバグなんですが。） ２点目。 CMS上のサービスを使って良い悪いは、誰が管理しますか？（権限と言う意味で） 使える最初のデフォルトセットの選定は部署の改変に耐えられる物なのでしょうか？ ３点目。 上記に関連して。 例えば、CMS上で購買発注と、経費決済があったとしてSODは誰が管理しますか？ （BPMSで作ったとして作ったときに決めておくと言うのはアリだと思いますが、漏れてた場合は・・・？） ４点目。 このBPWeb2.0を意識して作れとベンダーを啓蒙するのとどっちが早い and 安い？ | ||||||||||||||||||||||||||||
|
投稿日時: 2008-01-04 18:48
ｍarkです。いろいろとご質問ありがとうございます。ただ個別に答える前にもう少し書いておいたほうがいいと思います。それから論を進めていきます。
つぎのポイントは、このプラットフォーム上でどうやってシステム開発するのかという問題です。このとき、前提としてマスタデータはすでにあるという前提です。もしないようなら、モデリングをしてきちんとマスタデータを揃えておく必要があるのは言うまでもありません。 いま、システム開発という言葉を使っていますが、気持ち的には開発ではなく構築ですね。業務システムを開発するっておかしいですよね。とくに、ユーザの業務プロセスを開発するわけではないのでちょっと変ですよね。まあ、ここらあたりはあまり目くじらをたてずに開発としておきましょう。 開発の手順はあるプロセスを特定したら、そのなかでやっている仕事を抜けがないように順番に書き出します。それをもとに書類の要素を抽出しそれらを書類化していきます。書類化は書類の作成（仕事の依頼受付）から承認までを一括りとします。書類というのは、伝票とか帳票ではなく、依頼書とか指示書とかいう類のものです。何も実際に書類がなくても仮想的に発行するように考えます。例えば「在庫引当」なんては、あたかも「在庫引当依頼書」を作ったようにするわけです。 それを、BPMSのモデラーで記述します。普通のBPMSでは、アクティビティを並べて線をひくのをドラッグ＆ドロップで簡単に書くことができます。たとえば、見積プロセスであれば、仕様書―見積依頼書―見積書というような感じです。そして、それぞれのアクティビティのプロパティと必要データの設定を行います。それができあたらデプロイしてアプリケーションの完成です。プラットフォームを三層に分けたおかげでBPMSの開発作業はたったこれだけです。もちろんコードレスです。 さて、次にCMSの方です。ここではまず、サイト構造（サイトマップ）設計を行ないます。書類はコンテンツの中のドキュメントとかページのようなものを選択します。書類の様式にあったアイテムを選んで、必要情報を書き込む。そこには、BPMSのデータスロットから自動取得したデータ項目の入力フィールドがAjaxを使って埋め込まれている。 その他、参照データのファイルや画像、リンクといったものを配置しておく。ロゴとかポートレットなど、見た目についてはユーザが自由に好きなようにカスタマイズすればいい。 そして、BPMSとCMSとの連携はWebサービスを介して行なわれ、BPMS側のアクティビティのIDやステータスを取得する。 あとは参加メンバーの登録ロールの設定（作成者や承認者）を行なえばよい。 ざっと、こんな形でCMSを設定していくことになるが、基本的にはここでもコードレスであるが、正確に言うと、コードを書かなくてはいけない場合もある。 それは、BPMSとCMSのつなぎのところと新規アイテムの生成がいる場合である。つなぎのところは予め作っておけば大体いけるが、新規アイテムというのは書類のことであるので新たな書類が発生するとそれにあったものを作る必要がある。ただ、これは、できたものをライブラリー化しておけば、徐々に新規作成は減っていくと思う。 ホントにざっくりとだが概要を書いたのですがいかがでしょうか。 | ||||||||||||||||||||||||||||
|
投稿日時: 2008-01-04 19:35
markです。一応「BPWeb2.0」についての概要を書きましたが、最初の議論をなぜこうした概念がでてきたかの背景のようなことから始めたいのですが。というのもいま提示したものの良し悪しを最初から議論するのもいいのですが、もともとこういったフレームワークを考えたのは現状のシステム開発のやり方に疑問をもったからです。従ってこの問題意識を共有しないと議論がかみ合わないような気がします。
すいません。ご質問を受けておきながらはぐらかすようなことを言って申し訳ありません。もちろんこれまでいただいたご質問はRemarkしておき、おいおい議論するつもりです。 私は、20年以上のエンドユーザ経験と10年以上のシステム開発経験（といってもプログラムを書いたこともなく、プロジェクトメントだけですが）から言えることは、一所懸命正しくシステムを作っても本当にユーザの役に立つ（事業に貢献できる）システムになっているのだろうかという疑問です。 私は、多くの企業でなかなかで着ていないのではないかと思っています。少なくともコストに見合うものは少ないのではないのでしょうか。 ここの立脚点をどう評価するかです。いまのようなやり方で顧客満足度の高い物ができるのでしょうか。 みなさん、現状のシステム開発は問題がないのでしょうか？問題があるとしたらどんなことなのでしょうか？ | ||||||||||||||||||||||||||||
|
投稿日時: 2008-01-05 12:57
markです。前回現状のシステム作りは問題があるのかないのかという設問をしました。そして私は現在の企業情報システムはユーザが満足するものを作り出せていないという指摘をしました。この点をもう少し考えてみましょう。それは、ユーザの中の誰が満足していないのかということと、作り手であるSIerも同様に満足していないのかという点です。
まず最初の点ですが、ひと言でユーザと言っても企業の場合は、トップマネージメントであったり、ミドルマネージメントや担当者といった人たちが考えられます。では、システムは誰のためにあるのでしょうか。経営者のためでしょうか。私は、違うように思います。経営者の一番の関心はなんでしょうか。それは、「事業構造論」と「人事」のような気がします。この２つにとってシステムの占める役割は少ないのではないでしょうか。 次に、ミドルマネージメントはどうでしょう。事業部長とか部門長にとっては、自分が経営から任された事業とか業務プロセスを運用・管理することが最も重要なことになります。そこで重要なのは事業の状況や業務が可視化され、自分の手でコントロールできることです。 また、ユーザ担当者は、与えられた業務を正確に効率的にこなしていくことが求められます。がしかし、どちらかというと“上からやらされている”感じがあると思います。パッケージ導入などはこの傾向にならざるをえません。 こうしてみると、どうも情報システムというのはミドルマネージメントのひとたちのためにあるような気がしませんか。 そのミドルマネージメントの人たちは現状のシステムに満足しているのでしょうか。私はどうも否定的です。ビジネスの状況が結果でしか見えていないのではないでしょうか。死体解剖的であり、生体ドッグ的なマネージメントになっていないのです。 担当者の方もお仕着せのシステムで使い勝手が悪いのでインフォーマルな仕組みを自分で作って(Excelが多い)、属人的作業を行なっているように思えます。 一方、作り手側のSIerどうでしょうか。その前にSIerと顧客の関係をみていきましょう。日本のユーザは、自分たちの業務システムなのにどうも自らの手で作ろうとしていないように思えます。これは、メインフレーム時代から続いていて、その時代も終わったというのにいまだに残っています。ITのことはよくわからなから、専門家であるSIerにまかせばいいということになっています。 そして、ITの専門家がエンドユーザから彼らの仕事や業務フローをヒアリングして、システムに載せていくというやり方で開発してきました。そのとき、どういうことが起きるでしょうか。 ずっと、下に示す２つのジレンマを抱え続けているように思えます。 （１）アプリケーション仕様のほとんどが、結局、ユーザの恣意でしか決まらないこと 仕様を決定付ける科学的、工学的なモデルが存在しない （２）情報システムと人間の境界が、元来不安定であること 実業務の様々な例外をコンピュータ上に乗せるか否か ということで、ユーザがなかなか仕様を決めてくれない、決めてくれたとしてもカットオーバー直前で仕様変更される。決まって、言った言わないの争いが生じる。従って、見積りもいい加減にしか出せない。最後はお客さんとの力関係で料金が決まる。これだけの人月がかかったのでおカネをくださいといっても、昔はハードよりも安いのではいと言って払ってくれたが、いまやチープ革命でソフトウエアは安いというのが浸透しだしているため、回収しにくくなっているのではないでしょうか。従って、SIer側もいまのままでよいとは決して考えていないと思います。それと、「工事進行基準」という会計基準の変更が大きなインパクトを与えると私は思いますので、それに対応した変化をしないと大変なことになります。 ということで、システムそのものの構造やSIerとユーザの関係など、いわゆる構造的な問題とシステム開発技術上の問題が大きく横たわっていると私は考えています。 こうした企業情報システムの抱える問題点を解決していくには従来型のシステム構造や方法論の延長ではもう限界ではないかと思うのです。 | ||||||||||||||||||||||||||||
|
投稿日時: 2008-01-05 21:47
以下はkumaさんコメントに対してです。
私もkumaさんと同意見です。 三層構造が合理的でそれを現実システムとする 開発手法という様に意味づけています。 よろしく_______________________________________
私の解釈では 「三層アプリケーションプラットフォーム」はシステムの構造 そのものであり 「ソフト開発手法」はシステムを構築していく方法論 です。 システム構造が方法論の一要素になるかもしれませんが 両者が同一のものではないと思っています。 [/quote] [ メッセージ編集済み 編集者: konibi 編集日時 2008-01-05 21:49 ] | ||||||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.