ここでは日々思いついたこと、かつて経験したことなどをランダムに記述していきます
2025年03月01日
＜ERPを進める前工程でやるべきこと＞
まず以下のことが成立しているか確認しましょう
Business case：ビジネス上の目的を示す企画
「プロジェクト憲章」は文面化されているか？
どのように経営に寄与するか定量化されているか？
その定量化は計測可能か？
プロジェクト責任者は明確になっているか？（兼任は原則NG)
業務改革方針
業務課題は構造化され明文化されているか？（手間がかかるとかはNG)
業務を何からどう変えるかを文章化しているか？
現業部門は合意しているか？
現状との差異は把握され、明文化されているか？
現状との差異解消方針、優先順位は明文化されているか？
当該解消方針は現場の合意を得ているか？
システム化方針
機能分担が記載されていない状態ではないか？
要件は構造化しているか？
Target Operation Model（作るべきは業務フローではなく業務モデル）
各プロセスのInとOutが定義されているか？
プロセスのInの情報源はすべて明確に定義されているか？
プロセスのOutの基準が定義されているか？
プロセスの担当「者」が定義されているか？
チェックリスト
Business case
以下の文言は放置しないこと
具体的な対象データと管理行為の目的が定義されていない「管理」
目的語の無い「改善」
業務改革方針
対象業務内容が定義されていない「改善」は無いか？
目標値がない「改善」は無いか？
優先順位が定義されていない「改善」は無いか？
副作用が検討されていない「改善」は無いか？
構造化できていない業務要件はは無いか？
システム化方針
文章化されていないシステム要件は無いか？
構造化されていないシステム要件は無いか？
イメージ図しかないシステム要件は無いか？
Target Operation Model
In-Outが各プロセスで定義されているか？
必要事項、決定事項、決定担当者、決定基準が定義されていない「会議」は無い
2025年03月01日
＜ERP開始時に準備しておく根回し事項＞
人間は変化を嫌うものです
現場を敵に回してしまうとほぼ100％迷走し、訴訟に発展するケースも多い
課題解決を理由にすれば現状オペレーションから変わることを現場に納得させやすい
システム老朽化対策は情シスの都合であり理由がそれだけなら現場は現行保証を要求する
システム変更で生産性が落ちたら怒られるのは現場。情シスが変わりにマスタ設定をやるとかコミットしない限り前に進まなくなる
経営層を巻き込んだとしても同じ。工数が倍になるから人を増やせと迫られて経営層が取り下げた事例もある
システムに合わせましょう、と言ってしまった場合、以下の疑問に反論できるか？
手形をなくせとか、値段決めてから発注しろなど欧米の商慣行に合わせるのは困難では？
かんばんなど日本の強みになる方式は機能として実装されていないのは事実では？
通常ERPにかんばん運用を行う機能は無い
「XXXに合わせるのがグローバルスタンダード」と言われてトラブルを多発したが当時と何が違うのか？
トラブルの大半の原因はアドオンではない
システムコストが安くなっても現場の工数が増えたら意味がない。
2025年03月01日
＜ERP開始時の理論武装＞
メリットがあれば人間は動きます
某外資系のように使うのが嫌ならクビだ、と言えるくらいのけん引力がない限り、現場のメリットを具体的に語らないと反発されるだけになる。⇒
俺はこんなもの使わねえ、と吐き捨てた購買担当者もおられます
課題は仮説ベースででも掘り下げて具体的メリットを強調する（自動車部品のケースの例）
量産に補給品が入ってくると残業が増える⇒
システム入れたら残業が減るのか？と聞かれて困ることが多いので以下のように論理だてて説明する
問題仮説：量産ラインにおいて小ロットの補給品が急ぎで入ると全体の効率が低下して計画が達成できない
課題仮説：補給品に需要に見合う在庫がなく、急ぎで割り込んで生産が乱れる
解決仮説１：補給品のサプライチェーン計画に余裕を持たせ、急ぎの生産要求を抑止、計画に入れることを可能にする
解決仮説２：補給品のラインを一部試作ラインに移管し、量産品への影響を最小化する
システム解決仮説１：サプライチェーン計画ツールを導入し、補給品需要を動的に見直す仕組み、担当者を導入する
システム解決仮説２：日バケットの生産計画を半日単位にし、半日前変更をシステム運用として可能にする
システム解決仮説３：補給品のサプライチェーン計画と量産計画を合わせて発注できる仕組みに切り替える