ユーザ目線のシステム作り：SOA（BPM＋Web2.0）

投稿者

投稿内容

mark: 常連さん; 会議室デビュー日: 2007/12/31; 投稿数: 35

投稿日時: 2008-01-08 18:49

引用:
七味唐辛子さんの書き込み (2007-12-31 12:34) より: まずはお手並み拝見だな　コーディング無はともかくデータベース定義あたりは、どうなのよ！　と思ってしまいます。実は単なるパッケージ製品で、各種パラメーターをいじくると想定業務ができあがるとか？

データベースの定義は、マスタと勘定科目データは構築されている前提です。ここではBPMSのデータスロットの持ち方とCMSのコンテンツおよび参照データの構成などを設計することになります。
業務向けパッケージ製品ではありません。使うツールはBPMS製品です。機能は主としてプロセスエンジンのところです。CMSはオープンソースでもかまいませんが、フレームワーク、テンプレートといったもので、ある業務を想定しているわけではありません。

mark: 常連さん; 会議室デビュー日: 2007/12/31; 投稿数: 35

投稿日時: 2008-01-08 18:51

引用:
Anthyhimeさんの書き込み (2008-01-02 18:50) より: 基本的なデータモデル、ビジネスプロセスはERPみたいに構築済みなんでしょうな。会計、人事、営業、顧客情報管理、調達は欲しいですね。

データモデルはそうですが、ビジネスプロセスはここで作っていきます。
アプリケーションについてですが、これは後で議論していきますが、向き不向きがあります。また、会計や人事のようにその全体をサービスコンポーネントとして括ってしまうことも考えられます。要するに、プロセスが少なく変更があまりない定型化された処理は、それをブラックボックス化することもありだと思います。この技法は例えは調達なんかは適しています。

mark: 常連さん; 会議室デビュー日: 2007/12/31; 投稿数: 35

投稿日時: 2008-01-08 18:56

引用:

加納正和さんの書き込み (2008-01-03 23:30) より:

残念ながら、ここでデータが確定したなら、ERPに流れるしかないと思います。
正確に言えば、BPMSがまったく不要です。なぜなら上記の意味の「トランザクションデータ」は業務に不要ならいらないし(「試行」レベル)「トランザクションデータ」が必要なら、それはERPに流さざる得ないからです。

データが確定いたらERPに流れるのはそのとおりですが、そのデータを確定していくには多くの場合あるプロセスを経て確定していきます。例えば、前にも書きましたが、見積データにしても、仕様、見積依頼先などを順番に決めていきます。単純に生産実績を登録のようなものでも承認というプロセスを経ています。従って、BPMSが全く不要ということではなく、ERPの中のフロー機能を使うか、BPMSを使うかの差になるように思います。私は、プロセスの可視化という意味でBPMSの使用を薦めているわけです。

mark: 常連さん; 会議室デビュー日: 2007/12/31; 投稿数: 35

投稿日時: 2008-01-08 18:59

引用:

加納正和さんの書き込み (2008-01-03 23:30) より:

BPMSの場所で問題が発生しない以上(「試行」しているだけなら、誰も本気でデータ整備しようと思わないから)結局はERPに手を入れて業務を実装するだけになると思います。

で、それであるならCMSは、たんなる「だべり」と一緒であり、やるだけ無駄です。
というか、CMS→BPMS→ERPとして、連携させる必要がありません。各独立にシステムを作ってすり合わせたほうがましです。

ということで、標準化を考慮しない大多数のシステムと同様、各システム「だけ」に有用な方法に見えます。

あるシステムで、その「BPWeb 2.0」とやらが良さそうに見えることは否定しませんが。

さらにいうなら、その「BPWeb 2.0」とやらは、システムの可動範囲、なんといえばいいのか、仕様を変更できる範囲をCMSや、BPMSに移しただけのように見えます。

結局は、一番重要な「どこを」仕様を柔軟にするかという問題をCMS、BPMSという単語に
仮託しているように見えます。それはシステム設計の一部。で重要だったり重要じゃなかったりする一部だと思います。

ということで、本質的なところは変わらないような気がしますが。。。

このご意見のポイントは、ERPの守備範囲をどこまでにするかということと「BPWeb2.0」が適している業務はどこにあるのかということではないでしょうか。
すなわち、何でもERPの中で処理するようにするのか、ERPは必要最小限の役割にするのかという議論です。私は、ERPは決算システムとして機能させてどちらかというといまの機能を縮小させたほうがよいと考えています。ここは議論になろうかと思います。

また、もうひとつのご指摘の柔軟性のところですが、おっしゃっていることは大体わかるのですが、仕様を柔軟にするかという問題をCMS、BPMSという単語に仮託しているわけではなく、それらのもつ機能に仮託しているわけで、そうした構造にしたことが重要でこうした考え方は従来なかったものであると思っているのですが。

また、SIer視点、開発者目線からビジネス視点、ユーザ目線に変えることは本質的な変化だと思っています。

mark: 常連さん; 会議室デビュー日: 2007/12/31; 投稿数: 35

投稿日時: 2008-01-08 19:01

引用:

るぱんさんの書き込み (2008-01-04 16:31) より:
るぱんです。

あらかた加納さんが書いてるのですが・・・。
僕なりにわからない点を書いてみました。

１点目。
データのつなぎ目を誰がメンテナンスするの？
ユーザーにやらせるの？
ベンダーに責任が落ちてこない点では大賛成。
具体的に例を出すと、BPMS上、別バージョン同じBPMがあったとして、
稼動時期的な不整合は誰がどのように吸収しますか？
（もちろんバグなんですが。）

２点目。
CMS上のサービスを使って良い悪いは、誰が管理しますか？（権限と言う意味で）
使える最初のデフォルトセットの選定は部署の改変に耐えられる物なのでしょうか？

３点目。
上記に関連して。
例えば、CMS上で購買発注と、経費決済があったとしてSODは誰が管理しますか？
（BPMSで作ったとして作ったときに決めておくと言うのはアリだと思いますが、漏れてた場合は・・・？）

４点目。
このBPWeb2.0を意識して作れとベンダーを啓蒙するのとどっちが早い and 安い？

１点目
データのつなぎ目というのはどういうことでしょうか？データそのものの保障はユーザですし、データの連続性ということではシステムではないのでしょうか。
バグの問題はうーん？

2点目
CMSは基本的にはユーザが設計しますからユーザが管理します。そこには、承認権限を持たした管理者を置くのでその人が行ないます。
改変はその程度で耐えられるかどうか決まりますが、極論すればかなりのカスタマイズは可能です。

3点目
SODというのは職務分掌のことでしょうか。CMS上でロール設定をしておきます。そしてBPMSではその承認がなければアクティビティはオンになりません。

4点目
ベンダーを啓蒙することと何を比較してでしょうか？ユーザ自身で開発することでしょうか？
もしそうなら、そういう比較にはならないと思います。現実的には、ユーザの意識が高いあるいはある程度のスキルがある場合は、ユーザ自身でやってしまいますが、そうでないユーザはかなりベンダーが助けてやることになります。

[ メッセージ編集済み編集者: mark 編集日時 2008-01-08 19:25 ]

mark: 常連さん; 会議室デビュー日: 2007/12/31; 投稿数: 35

投稿日時: 2008-01-08 19:04

引用:

Ａｈｆさんの書き込み (2008-01-06 21:10) より:

今回言われているシステム規模というのが、どうも「全社」などの範囲が大きめな話に読みとれるのですが、今回議論したいのはそのようなレベルで構築するシステムの話なのでしょうか？
構築するシステムの規模や種類によっては向き、不向きがあると思うのですよ。

企業のシステムはまず「全体」を考えるべきだと思います。そのなかでどこの部分をシステム化すべきかを検討します。これは会社の規模や業務の標準化具合、従業員のレベルなどを勘案して決めていきます。そして、システム化はおっしゃるとおり規模や種類によって方法やツールも変わってきます。私は、「BPWeb2.0」はどの規模の会社でも通用すると考えています。規模が持つ特殊性はなんなのでしょうか？安定性の要求？セキュリティ？可用性？少なくとも、プロセスという場合、ある特定部署固有になることが多い（全従業員対象の申請なんては別として）でしょうから、会社の規模にはあまり左右されないかと思っています、いずれにしろ論点のひとつですね。

mark: 常連さん; 会議室デビュー日: 2007/12/31; 投稿数: 35

投稿日時: 2008-01-08 19:06

引用:
Ａｈｆさんの書き込み (2008-01-06 21:10) より: この点については非常に同意です。ユーザー側にとってはもっとも望ましいことだと思いますね。今のところSI側にかかる負担（技術、人員の教育など）を解決できる手法がないのが問題なだけで。

この解決をめざしているのがこの手法です。また詳しく説明していきますが、コードを書かない、仮に書かなければならなくなっても、それはスーパープログラマーに書かすということがヒントです。

mark: 常連さん; 会議室デビュー日: 2007/12/31; 投稿数: 35

投稿日時: 2008-01-08 19:09

引用:

七味唐辛子さんの書き込み (2008-01-06 21:53) より:

言語的な問題はありますが、そういったことは１０年前ぐらいから言われています。
最近は話題にはあがりませんが、ＲＡＤ（Rapid Application Development）
と呼ばれる手法で、この概念が発表されたころはＶＢとかDelphiとかが
ＲＡＤツールとか言われてました。

プロトタイピングもこの概念に含まれます。

参考
http://journal.mycom.co.jp/series/stratesys/011/index.html

10年前から言われていることが解決されていないのが問題ではないでしょうか。
RADの件ですが、私は１０数年前にDOA－RAD、プロトタイピング－タイムボックスで生産管理システムを構築した経験があります。しかしながら、何とか稼動させましたが、正直言って苦労しました。ひとことで言うと難しいのです。開発者がみなこの方法論を理解できないし、ERDはユーザの人は読めないのです。
ですから、一部のスキルの高い人だけができる方法論は有効なものだとは思えないのです。しかもこうした方法論は開発者側の生産性向上というところに重きを置いてあるような気がします。
従って、ユーザの人でもシステム構築ができることをめざしているわけです。

«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

ユーザ目線のシステム作り：SOA（BPM＋Web2.0）

スキルアップ／キャリアアップ（JOB@IT）