賢いシステム受発注マニュアル

・工場原価管理システム受発注の相場

工場原価管理システム及び全社経理システムを構築する場合の例をお知らせします。
工場原価種類は多岐に渡って、維持が大変だといったことはございませんか?
また、会社内部要因だけではなく、外部要因(会計基準の変更)などへの対応に長い期間がかかるといったことはありませんか?
工場の生産における活動は、(輸入)、材料納品、材料検収、材料倉庫入庫、製造へ出庫、製造着手、材料在庫の消込、製造完成、製品倉庫入庫、仕損、振替、支給、出荷場所への出庫、出荷、(輸出)、得意先での製品検収があります。輸出輸入も含めると16の活動があり、経理における仕訳作業(貸方・借方の各勘定や各部門の金額(数量・単価(原価))が発生します。
単純には16プログラムだと、約SE 2ヶ月の概要基本設計費、SE 2ヶ月分の詳細設計、プログラマー3ヶ月の費用が発生します)合計200万円+200万円+240万円=640万円発生します。開発以外に開発マシンの性能やデータベースの費用が発生します。

・工場原価管理システム受発注の契約の結び方

・発注者の方へ

各生産各活動によってどういう仕訳が発生するか場合分けをはっきり定義していないと、開発後に修正がかかり、開発予算をオーバーしてしまうことがしばしば発生し、起案書の再作成などの間接的な時間を浪費してしまいます。例えば、材料検収にみると、仕入先が一般仕入先、関連会社、下請け仕入先、輸入仕入先で仕訳が違ってきます。一般仕入先は借方が買掛金、関連会社は単に在庫の移動での部門振替、下請け仕入先は材料検収ではなく材料納品時点で買掛金が発生、輸入仕入先は海外の港を出た時点で借方:移動中在庫、貸方:売掛金が発生します。要件定義はしっかりたてるようにしてください。ただ、追加要件をまったくなくすことは難しいので、追加要件が出てきたときに受注者に早めの対応ができるように、保守契約をきちんと結んでおくことです。また、全社経理システムへの連携レイアウト(全ての勘定で共通のレイアウト)、各項目(勘定コード、部門コード、金額計算方法、金額桁(通貨別単価、通貨別金額))をきちんとテーブルにしておくこと。テーブルの維持は重要です。システム要件出し、稼働、1年後、発注者の担当が変わるとさらに何世代にもばると、ここを少しこう変えたいといった要望が出ても、社内に分かる人がいなくなり、ブラックボックス化してしまいます。
また、社内要因(工場の分散化、海外進出、工場別に損益計算書を作成したい)や外部要因(会計基準の変更、日本国内での外貨建て商品取引の開始)によっても柔軟な対応ができるかシステム機能をよく確認しておくことです。

・受注者の方へ

開発ステップでの開発の背景である問題点・要件定義・概要設計(外部設計)・基本設計・詳細設計(+プログラミング)・テスト・稼働での各マイルストーン毎に、発注者の承認を得ることが大事です。承認を得ないで次のステップにいってから、要望が変わって、元に戻ってしまうことがよくあります。その負担は発注者が負うのか受注者の聞き取り方の悪さか、問題になるため、承認を各マイルストーン毎にとることが肝要です。
1本の契約で作成したシステムの機能性が高ければ、別の案件でも発注していただける可能性が高くなります。定期的に発注者の新しい要望や不満などを社内で共有し、発注者へ提案できれば受注をgetしやすくなります。また、維持・保守では不具合が発生した場合は、発注者の業務へ影響を与えないように、常にモニタリング機能で監視し早い対応をします。保守費用は適切な価格を設定します。

・どういう会社にどういう体制を組んでもらうか

発注者側:責任者、リーダー(実質的な要件責任者)、工場原価部門、全社経理担当者(経理部門と経理システム者)
リーダー:発注者と受注者の進行役と要件責任
責任者:リーダーから説明を受け決済できる人
工場原価部門:各活動でどんな仕訳を作成するか細かな要件が出せる人
経理部門:全社の会計にあっているか確認できる人、勘定や部門などのコード決定できる人
経理システム者:工場からデータの連携方法(レイアウト、コード、受信日時、等)、経理システムに正常に取り込み処理を行った結果を返信する方法、異常時の対応方法

受注者側:責任者、リーダー(実質的な管理者)、担当SE、(外部開発会社)
リーダー:発注者側のリーダーと協力して、体制を維持して、要件・スケジュール管理をする人、外部開発会社への依頼内容な契約内容を作成できる人
担当SE:各設計段階の仕様を作成できる人。外部関連会社に仕様を提示すること。如何に複雑なシステムから共通な部分を見つけて、サブルーチン化できる人。
外部開発会社:どこの段階から開発・維持に関わるかによる。WEB入力・出力系、バッチ処理系。夜間などの保守にも対応できる会社に参加していただく。

・システム見積り高い(失敗する体験談)

開発は、発注者(業務部門)の各活動毎に開発を行えば、いいように思えますが、工場が1箇所でなく複数の工場があったり、海外工場ができたり、会社の合併など会社の内部・外部要因で、要件が違ったりして、最悪 16本のプログラムを各工場別に作ってしまうことになりました。例えば、日本とアメリカに工場がある場合、金額の計算だけでも、日本は小数がなく円単位ですが、アメリカはドル単位ではなくセント単位で四捨五入するといった具合で、開発費はいただけますが、各工場の要件を覚えないといけなく(ある意味、ブラックボックス化)、維持が大変になりました(保守時にトラブルが発生した際に仕様がバラバラだったため迅速な対応が取れなかった)。
WEB系だと、入力・照会は、ユーザーに受け入れやすいが、大量のデータを扱うバッチ処理を行うと、処理に数日かかるようなことがあった。(データを社内システムへ転送して、COBOL等のコンパイル言語で処理したら、レスポンスがよくなった。)

・システム開発工数削減(成功した体験談)

16本のプログラム開発を行うのではなく、各活動ごとにどんな仕訳を作成すれば良いのか、仕入先のマスタに、一般仕入先、関連会社、下請け、海外仕入先などの記号をつけました。このように各活動とそれに付随する条件例えば10段の条件設定ができるマスタを用意して、プログラムの条件を10段の分岐をして、仕訳データを作成するプログラムと、その条件マスタの登録画面1つ(発注者から条件を聞いて受注者がマスタを修正する)の2本のプログラムだけで対応できるように設定しました。金額の計算法も、小数何桁で四捨五入するか、あるいは韓国やベトナムの通貨だと整数2桁四捨五入するなどの、サブルーチン対応しました。

工場原価管理ビジネスを伸ばせた体験談

発注者の会社自体の内部事情ではなく、外部要件として、決算報告書を日本では2013年から、米国式会計基準ではなく、IFRS(国際財務報告書基準)に移行する必要がありました。これまでは、会社として、会社を出荷した時点で売上計上するか、得意先の検収時点で売上計上するか自分で決めることができたのですが、IFRSでは、”得意先の検収時点で売上計上”になったため、多くの会社では、売上のポイントをずらすシステム変更が必要だったと思われますが、上記のマスタにしていたため、出荷で売上仕訳を作成するのではなく、出荷では移動中在庫仕訳にして、得意先検収で売上仕訳にするマスタ変更だけですみ、開発工数が少なく、発注者様に提案して喜ばれ、他システム案件の獲得にもつながりました。