Nexediの奥地さんが来日されているということで、SEA & FSIJ 合同フォーラム 2006年9月~オープンソースERP「ERP5」によるビジネスとテクノロジー~に行ってきました。
他の参加者(嘉平さん、yutakashinoさん)のレポート:
・2005/01/12 Plone研究会「ERP5」
・2006/09/15 SEA & FSIJ 合同フォーラム
・2006/09/15 Nexedi 奥地さん
一応オフレコの部分は削除したつもりですが、自分用のメモを公開してみます。
■ERP5
Pythonで書かれたオープンソースERP
■ERPの概念
ERP = Enterprise Resource Planning
短いプロジェクトで3ヶ月、長いもので1年から3年
典型的な会社
開発部
人事部
経理部
販売部
マーケティング部
→各部署でたらい回し、情報共有がされていない
ERPフレームワーク
人事管理(HR)
会計管理(Accounting)
生産管理(PDM)
顧客管理(CRM)
Webパブリッシング(CMS)
紙:カタログ、パンフレットも
オンライン取引(eCommerce, eProcurement)
→データの重複は悪、同期の手間がかかるし、システムも複雑になる
■ERPの最近の潮流
オープンソース
カスタマイズ性能
ベンダーロックインからの解放
コスト削減効果
ベストプラクティスの提唱←→実際の業務はそれぞれのやり方がある
Webベース
ユビキタス
ファイアウォール
インターネット
日本では気付きにくいが、世界には回線事情がとても悪い会社もある
衛星回線、パケット遅延0.5秒、入力タブの移動で2秒かかる製品も?
■ERP5とは
ERP5はシミュレーションベースのERP
会計ベースはシステムのずれに弱い
出荷、一日遅れで届く、検品すると数が違う
ERP5は…
事実だけを1次データベースに保存する
2次データベースはMySQLを併用して高速化
導入実績:
服飾産業、航空宇宙産業、中央銀行、病院、政府機関、地方自治体など
通貨の発行管理、窓口業務の管理、紙幣の追跡、入院・医療行為の管理など
といったニッチな複雑な業務もERP5のフレームワーク上で構築
アパレル業界(ERP5の最初の顧客)では
大きさ、色、デザイン、バストサイズなど...多次元データの商品を扱う
雑誌での評価
Decision Informatique(フランスの経営者向けIT雑誌)
ERP5が最優秀賞を受賞
Computerwoche(ドイツで最も有名なIT雑誌)
ERP5を特集、infoterra 偵察衛星写真の販売業務でERP5を採用(SAPと比較)
ユニログノジカCMS、ヨーロッパで第3位のコンサルティング会社
■なぜOSSがビジネスになるか?
Nexedi(研究開発)
パートナー(インテグレーション)
顧客(利用、メンテナンス)
プロジェクトの複雑度
=ワークフロー+文書+カテゴリ+インタフェース
プロジェクトの期間
=意思決定が行なわれてから現場で利用できる
水準に達するまでの経過時間
お金はある?時間はある?
↓
1. Do it yourself (お金はないけど時間がある)
2. トレーニング (→OSSビジネス)
3. コンサルティング(→OSSビジネス)
4. No Way (お金も時間も全然ない)
■ERPの技術的特異性
ミッションクリティカル
止まるとヤバイ
データの種類が多い
50~300が普通
データ量が多い
1000取引/日でも一年で30万取引
国民全員だと数十億のオブジェクト数
ちなみにヒトゲノムは4GB
書き込みが頻繁
キャッシュ効率やスケーラビリティの問題
■技術面から見たERP5
99% Python(残り1%は主にC)
オブジェクト指向(後付、2.2ぐらいからマシに)
メタプログラミング(データ種が多い、クラスの動的自動生成)
Lisp?(括弧が多い) Ruby?(大規模開発には向いていない)
Zopeベース
オブジェクト・データベース(ZODB)
Through The Web(TTW)、ユーザにとってウケがいい
Productによる拡張
キャパシティの計算などがCで書かれている
javaで書かれているのもあるけどgcjでコンパイル
■ZSQLCatalog
Zope Product
Zopeの機能を拡張
ZCatalog互換
Zopeの標準機能からの以降が容易
オブジェクトのインデックス化
リレーショナル・データベースを利用
MySQL(単純に非常に速いから)
■O/R Mappingの問題点
Document
ID:1023
Title:Hoge
Content:Fuga
変更に弱い(Author:Okujiを追加)
ALTER TABLE はテーブルロックがかかる
テーブル数が多い場合、レコード数が10億とか、業務が止まる
列が多過ぎ
性能低下、システムの制限
ロックの粒度が粗過ぎ
数学的厳密性ゆえの宿命
表が多過ぎ
ロジックの分散、システムの制限
InnoDBはインデックスをロック、対象データの前後のレコードもロックする場合も
■オブジェクト・データベース
ID:1023
Serialized Data:0x821203FD678
欠点:検索がそのままではできない
→ZSQLCatalogによる解決
データベースを1次のZODBと2次のMySQLに分ける
Zope←オブジェクトデータ→ZODB
ZODB←遅延評価→MySQL
MySQL←検索→Zope
■ZSQLCatalogの利点
変更に強い
検索が速い
必要最小限の列で十分
少数の表で十分
低速なインデックス作成を後回しにできる
複数のデータベースを持つことによって
使いながらインデックスを作り直すことができる
(Hot re-index)
■興味のある方は…
詳細は http://ERP5.org で。ソースコード、RPM、Live CD をダウンロードできます。