目的
最小の“動く土台”を即作る。OdooデータとNeo4jが同じ世界に存在する状態を確立。
やること
- Docker Composeで起動
- Odoo
- Odoo用Postgres
- Neo4j
- KPI/RCA用のAPIコンテナ(FastAPIの殻でOK)
- Odooにサンプル会社・最低限の取引/在庫/購買データを入れる
- 接続確認
- Odoo UI
- Postgres参照
- Neo4jログイン
- API
/health
成果
- “ここからすぐ計算・説明へ進める”実行基盤
Phase 1:オントロジー最小
目的
ロジックの骨格を先に固定して、後工程のブレを防ぐ。
やること
- PoCのKPI階層を確定
- 症状KPI
- 原因切り分けKPI(材料/工程)
- スキルが説明要因に入る構造
- 依存関係の最小定義
- KPI → Component
- Component → 材料/工程ドライバ
- Step → RequiredSkill
- Step → Material
- 企業差分領域を明文化
- 組織/原価センタ
- 工程辞書
- スキル辞書
- 材料辞書
- 標準値(標準工数/標準使用量)
成果
- **「企業ごとの差分は辞書とマッピング」**と言い切れる設計コア
Phase 4:KPI計算
目的
まず“数字が出る”体験を作る。厳密会計より再現性と説明導線優先。
やること
- まずはPythonでOdoo Postgresを参照して月次KPI算出
- PoC最小KPIを実装
- 粗利益率/売上原価率
- 材料費率/加工費率
- 工数効率/手戻り率/不良率(取れる範囲)
- 購買単価指数
- 在庫回転率/Aging
- 計算結果を
- Postgres(
mgmtスキーマ推奨)へ保存 - もしくは一旦JSONで保存
- Postgres(
成果
- KPIの月次値と先月値の基礎データが揃う
Phase 5:原因仮説コメント
目的
PoCの“刺さり”の本丸。
材料 vs 工程 vs スキルの仮説順位と理由文を出す。
やること
- ルールベースの仮説スコアリング
- 材料:単価指数×材料費率×歩留まり/スクラップ
- 工程:工数効率×手戻り×不良
- スキル:悪化Step×RequiredSkill×低品質/手戻り集中
- 先月比コメントのテンプレ固定
- 断定しない
- 仮説順位 + 根拠Top3 + 次の確認ポイント
- “文章だけでも説得力がある”出力にする
成果
- KPIと同時に理由が返る状態(画面不要でも魅力が伝わる)
Phase 6.1:REST + Swagger
目的
“何が取れるか”を見える化して、開発と説明の共通言語にする。
やること
- FastAPIでRESTエンドポイント
- KPI定義
- 月次KPI値
- 先月比
- RCA結果(コメント付き)
- OpenAPIを整備
/docsでSwagger UI表示
成果
- 顧客/開発元に見せられるAPIの顔が完成
Phase 3:必要最小ETLで根拠強化
目的
“理由コメントの根拠の厚み”を上げる。
ただし全部同期はしない。
やること
- Neo4jへの投入を最小に限定
- 辞書(Org/Step/Skill/Material)
- 依存関係(Step-Skill, Step-Material など)
- 月次の薄い集計(材料単価/工程手戻り/工数増分)
- このETLは
RCAコメントの「根拠Top3」を強くするためだけに行う
成果
- コメントが一般論ではなく
“この会社の材料/工程/スキル名”で語れるようになる
Phase 6.2:GraphQL / GraphiQL(余裕があれば)
目的
将来の探索UIやnlq-dev連携の“便利な参照口”を作る。
やること
- 公開型を最小に絞って定義
- KPI/Component/Material/Step/Skill/Org
- MoMResult/RCAResult
- GraphiQLを有効化
- 役割を明確化
- GraphQLは探索/参照中心
- RESTは成果物/安定API
成果
- “自由に関係を引ける”将来像の足場
コメントを残す