パッケージソフトをカスタマイズしない。固有要件を「ハブシステム」で吸収した品質管理システム導入事例
はじめに
生産管理と品質管理、それぞれにパッケージソフトを導入しているメーカーは少なくありません。しかし両者を連携させようとすると、自社固有の要件を満たすためにパッケージソフト本体へのアドオンやカスタマイズ開発が必要になり、コストが膨らみます。
さらに厄介なのは、そのカスタマイズがパッケージ刷新時に足かせとなり、再度同じ開発が発生してしまう点です。
本記事では、メーカー様において、生産管理パッケージソフトと品質管理パッケージソフトを連携する「ハブシステム」を構築した事例をご紹介します。
システム概要
メーカー様にて、生産管理パッケージソフトと品質管理パッケージソフトを連携するハブシステムを構築しました。
取り組み内容
本プロジェクトの設計思想は明快です。パッケージソフトへのカスタマイズは必要最小限とし、固有の要件はハブシステム側で吸収する。この方針により、以下を実現しました。
- パッケージソフトの標準機能を活用し、アドオンやカスタマイズ開発を避けることでコストを低減
- 先々で老朽化したパッケージソフトを更新・置き換える際にも、連携先のシステムに与える影響がほぼゼロ
- 将来的な完全自動化に向けた土台を整備
カスタマイズ方式との違い
パッケージソフトをカスタマイズする従来のアプローチでは、マスタ、検査項目、ユーザー設定、ロット定義、頻度設定といった固有機能を品質管理パッケージソフト本体の内部に作り込むことになります。
この場合、パッケージを刷新すると再度カスタマイズが発生します。
一方、ハブシステムを介した構成では、これらの機能をパッケージの外側にあるハブシステム側に持たせます。
品質管理パッケージソフトは標準機能のまま利用し、生産管理パッケージソフトとはハブシステム経由で連携。
この構成であれば、パッケージを刷新した場合もカスタマイズは不要です。
固有要件を「どこに置くか」という設計判断が、長期的なコストを大きく左右することを示す事例と言えます。
副次効果
当初の狙いであった連携基盤の整備に加えて、現場業務にも改善効果が生まれました。
- システム連携由来の課題によって発生していた手作業を削減し、入力ミスによるリスクを根本的に排除
- ハブシステムに持たせたデータや条件から検査方式の判断を自動化。暗黙知や属人化していた業務が標準化
判断ロジックをハブシステム側にデータとして保持したことで、担当者の経験に依存していた検査方式の決定が仕組みとして定義され、業務の標準化につながりました。
変化に強く、拡張しやすい全社共通基盤へ
- システム刷新時にかかる手間や費用を抑えて、スムーズな置き換え対応が実現
- 複数工場における全社標準化、および検査業務の完全自動化に向けた基盤強化
ハブシステムは単なる連携の仕組みにとどまらず、今後の全社展開と自動化を支える共通基盤として機能しています。
まとめ
本事例のポイントは以下の3点です。
- パッケージソフトへのカスタマイズを避け、固有要件をハブシステムで吸収する設計により、導入コストと将来の刷新コストを同時に抑制
- 手作業の削減と入力ミスの排除に加え、検査方式の判断を自動化し、属人化していた業務を標準化
- 複数工場への展開や検査業務の完全自動化を見据えた、変化に強い全社共通基盤を構築
パッケージソフトのカスタマイズ費用や、将来のシステム刷新時の負担にお悩みのメーカー様にとって、参考になる事例です。
