前回は、島根富士通の新システム開発導入に当たり、背景・課題・対応方針をご紹介しました。
それらを振り返りながら、具体的な開発方針・ステークホルダーマネジメントについてご紹介します。
課題は以下の通りでした。
1, それまでの購買システムは汎用機やオフコンを前提に開発運用されていて、平均購買リードタイムは約二週間、サイクルは一日一回。
2, それに対し、パソコンの生産ラインに必要な購買サイクル一日数回、リードタイムは数日。
それに対する、開発方針は以下でした。
三つの方針について具体的な施策をご紹介します。
1, EDIの普及を100%に近づける。
当時日本はEDIについて後進国であり、閣内表中の整備が業界毎に進んでいました。
グローバルでは、ヨーロッパのEDIFACT、アメリカのANCI X12が主流で日本では外資 を除き、ほとんど実績がありませんでした。
富士通は、日本の電機機械工業会の標準であるEIAJ標準を採用し購買本部から事務局 に、課長級をアサインして何とか間に合せ汎用機の購買には既に実績を上げていました。
関連会社が開発したパッケージもあり、それの説明会を島根富士通の取引先に地道に実施 して行きました。第一の社内社外の協力体制です。
2, 購買発注は日次ではなく、処理速度をオンライン並みにして、一日に何度も発注する。
この実現が、一番大変でした。
当時の購買システムは、開発されて10年以上経っており、汎用機で稼働している部分で もCOBOLで約２２Ｍステップ、周辺も合わせると100Mステップ近く、どうなっている のか社内システム本部でも誰も分かりません。外注したからです。
三人プロジェクトで議論し、以下の作戦を決めました。
・発注伝票が発行されEDIに繋げれば良い。
・大量の管理帳票はパソコンにダウンロードして使う購買情報システムに一元化する。
・JCL（プロセスフロー）最低限必要なアウトプットから逆に追って行き、関係ない部分
は川崎工場で運用を続けるだけとし、分析対象から外す。
・既存システムの分析には、データ中心アプローチで設計開発された、AA/BRモデラー のベータ版を使用する。（この時点で蒲田のシスラボの開発部隊がプロジェクトに合流 しました）
簡単に言うと、必要以外のシステム資源は捨てて、今後の事を考えて、可視化するために ツールを使うという事でした。
3, 取引先とのリードタイムを見直す。
この部分も別プロジェクトが先行しており、所要量提示発注システムが稼働していまし た。
これを少し解説すると、いきなり発注するのではなく、先行き四週間、それ以降は月単 位で九か月の所要量を取引先に提示して、取引先のリスクで他社に売れるもしくは転用 できるレベルまでは仕込んでもらい、富士通向け最終工程だけをリードタイムとするも ので、単に取引先が製造にかかる時間ではなく、リスクの分岐点をリードタイムとして 再定義するというものです。これについても別部隊が説明会を実施していたので、前述 のEDIと合わせて実施することにしました。（第三の協力体制です）
以上が、実際に取ってきた試作です。それぞれの専門的な解説は別途ご案内します。
次回は、富士通の他の社内システム、販売・製造と購買システムの統合に触れます。
Comments