生産管理システムを設計する上で製造現場がどのようになっているかをご自身で確認し、理解することは非常に重要なことです。製造現場はどの業種にも共通する部分、業種や企業によって特異性のある部分があり、それらを見つけ出して区別することが必要です。
生産管理システムは製造現場の物、人、設備等を効率的にコントロールするためのツールです。現場を見ることにより現場をイメージしながらシステムを設計することが重要であり、それにより製造現場と融合したシステムを構築することができます。現場を見る主な観点として以下のようなものがあります。

生産管理システムの処理機能のうち50%以上が異常処理の対応と考えられます。
製造業では受注したものが各工程を通過して製造され、製品検査を受けて合格品として出荷されることが大半ですが、一部はその過程のなかで異常な事象を起こすものがあります。異常な事象の一部を列挙しますと以下のようなものがあります。

異常処理は正常処理に比べて数倍の機能が必要な場合があります。異常な事象は全体の一部だからと言って無視する訳にもいきませんが、全てをシステムに組み込む必要もありません。異常処理をシステム面、人的面のどちらで対処すべきかについては発生頻度、異常事象の生産管理における影響、重要性等を考慮して検討することが必要です。

製造現場は物づくりが本業であり、本業に専念してもらうために入力は極力少なく、かつ簡便化することが重要です。入力が少ないと当然入力ミスも少なくなります。
入力作業の負荷を出来るだけ軽減し、かつ情報を正確、迅速に取り込むための手法を考えてください。事例の一部を下記に列挙しています。

生産管理システムを構築するにあたり、まず第一にシステム構想（骨子）を作ります。
システム構想は業務内容、製造現場の状況、外部環境等を調査し、企業における問題点・課題、要望事項を取り込んで策定します。策定された構想がベースとなり、システムが構築されます。構築されたシステムは事務所、現場において業務と融合して運用されます。管理レベルの高いシステムを構築しても現場の管理レベルが低いと運用できない場合があります。運用できるかを判断してシステム構想を策定することが必要です。
導入したシステムが円滑に運用されてはじめて問題点、課題を解決することができます。

シンプルなシステムを構築することは、全てのシステムに当てはまりますが、特に情報が多岐に渡り連携している生産管理システムでは重要です。
生産管理には異常処理が50%以上と先ほどご説明しましたが、システム設計を行うにあたり、まずは正常処理の部分でシステムの根幹を設計することが重要です。
システムがシンプルに設計されているかは根幹部分が通常な業務処理になっているかに依存します。これは根幹部分のシステムを見ればシステム全体を理解することができることを意味しており、これを「システムがシンプルである」と考えています。
そのためにはシステム設計前の段階で業務の正常と異常部分が明確化されていることが必要です。システム設計において根幹部分に異常処理を組み込むと正常と異常との区別のないシステムとなり、システム全体を簡単に理解することが難しくなります。
異常部分はシステムの枝葉と考えて、まずは正常部分でシステムの骨子を設計し、次に枝葉である異常処理の部分を機能追加して設計してみてください。
枝葉の部分は発生頻度、重要性、開発予算等を考慮してシステムに組み込むか、人的対応とするかを判断してはいかがでしょうか。
シンプルなシステムは運用し易く、変化に対して柔軟に対応できると考えています。

システム開発の現場では、受注処理・製造指示など各業務をサポートする、いわゆるエンドユーザの関心事である機能要件に加えて、システムのサービスレベルを決定づけるものとしてインフラ・運用要件も重要です。このインフラ・運用要件の代表的なものは、データ容量・レスポンス時間・システムのサービス時間などです。
近年のハードウェアの進歩はとても速く、メモリのサイズやハードディスクの容量をそれほど意識しなくても、各メーカの代表的な製品を選択すれば、業務に支障のないシステムを構築することができるようになりました。しかし、機械である以上、故障やその性能限界を超えることは不可能です。そのため、導入当初では1時間で全てのデータをバックアップできていたシステムも、3年・5年とデータを蓄積するうちに加速度的にバックアップ時間が延び、翌日の就業開始時刻になってもバックアップ処理が終わらないなど想像していなかったトラブルに見舞われることもあります。
また鉄鋼メーカなどですと製造工程の特性上、工場が24時間365日稼動しており、システム機能とそのユーザ業務の兼ね合いからシステムのサービス時間を夜間のトラブル対応なども含めて検討しておくことが重要です。
さらに月次の受注情報を一覧出力する機能などでは、機能そのものを開発することは容易ですが、その情報量が多いとシステムに出力指示をしてから帳票を出力し終えるまでに数時間掛かるなど実際には使えない機能となってしまうケースもあります。
このようにインフラ・運用要件は、ユーザの中では「当たり前」と暗黙のうちに思われているもので主たる機能要件と表裏一体の関係にあり、システムを開発する側は設計段階から意識して検討しておくことが、使ってもらえるシステムづくりには必須と言えます。