| ||||||||||||
| 前のページ 1 2 3 | ||||||||||||
| マスタとトランザクションのデータ整合性 | ||||||||||||
ユーザの現行システムをヒアリングしていると「データがぐちゃぐちゃで信用できない」といった発言をよく聞きます。長年使ってきたシステムでマスタデータとトランザクションデータの不整合が発生しているケースは多いのですが、人間による正しい運用を前提としてデータの整合性を確保しようとしても限界があります。 内部統制が効いたシステムとは、運用に頼らずにデータの整合性を保つ仕組みを備えているものです。すでに伝票(トランザクション)に使用済みなのにもかかわらず、マスタデータを削除・変更できるような甘いシステムでは使っているうちにデータの不整合が発生するのは当然なのです。 | ||||||||||||
| フロントとバックのデータ整合性 | ||||||||||||
GRANDITは販売管理や生産管理などのフロントシステムと会計システムが統合されており、売上/仕入/製造などのフロントで発生する伝票が会計システムに自動仕訳処理される仕組みを装備しています。このようにフロントとバックのデータ整合性が確保されていますので、例えば販売管理での売上合計は会計の勘定「売上高」の合計と一致します。 ERPでは当たり前とされるこれら整合性も、フロントとバックのシステムをばらばらに作成している場合において不一致となっているケースがあります。確かにフロントは「粗い速報値」として精度を要求しない場合もありますが、内部統制における「情報信頼性」確保という観点により、日々の運用で使うフロント側データの精度向上への要請が高まっています。 | ||||||||||||
| 組織変更対応 | ||||||||||||
データの信頼性を損なう要因の1つに組織変更時の対応不備というものがあります。現代の企業は、市場や社会環境の変化に応じてタイムリーに組織変更を行いますが、システムがそれに対応できていないと、その都度大変な作業を要することになります。 そのため、GRANDITでは「組織変更対応」が標準機能として装備されています。組織図を履歴型で持てるだけではなく、ある部門で仕掛中の伝票を別部門に一括して移管できる機能も用意しています。 | ||||||||||||
| マスタデータの履歴管理 | ||||||||||||
GRANDITは組織だけでなく取引先や銀行などのマスタも履歴管理しています。取引先や銀行の合併や統廃合、社名変更などが発生しても、その前と後のどちらのデータも正しい名称で表示できるのです。 | ||||||||||||
| 業務データ変更管理 | ||||||||||||
基幹業務システムにおける伝票の変更は、昔から赤黒処理が行われていました。ある伝票を修正すると自動的にその伝票の赤伝が作成され、同時に新しい黒伝が作成されます。このような処理により、いつ、どのような変更が発生したかということを追跡できるトレーサビリティが実現できているのです。 また、データそのものに変更履歴をセットする方法も一般に使われてきました。最終更新日時や最終更新者などの列をデータに用意して、その伝票を操作したものが誰であったかを確認できる仕組みが提供されています。 最近では、これに加えて操作ログやエラーログなどログ(記録)を取る仕組みも併用されています。不正や障害などが発生した際に、その証跡を調査・追及できる仕組みが業務システムに用意されていなければなりません。 | ||||||||||||
| 通知機能 | ||||||||||||
不正検知やエラー発生時に単にログに書き出すだけでは不十分です。何らかの手段によって、いち早く管理者に伝えて対処してもらう必要があるのです。そのためGRANDITでは通知機能を用意し、Webやメールでメッセージを通知できるようになっています。 | ||||||||||||
| まとめ | ||||||||||||
日本版SOX法への対応で大変なのは、自社の業務手順を業務フローにまとめる作業です。その中から洗い出されるリスクや課題をIT、非ITなどのカテゴリに整理して、それぞれのRCMを作成する作業はかなり骨が折れます。 今回は、それらの項目のうちERPの守備範囲の標準的な課題を取り上げ、ERP「GRANDIT」での対応方法を参考として紹介しました。本連載を読み終えましたら、ぜひペンを手にして表1のチェックを行い、自社システムの内部統制状況を把握することからはじめてみましょう。 | ||||||||||||
| 前のページ 1 2 3 | ||||||||||||
| ||||||||||||
| ||||||||||||
| ||||||||||||

