日本版SOX法に対応するステップ導入法

ステップ1のスコープを設定するのは、当然です。関連企業まで含めるとかなりの大掛かりのプロジェクトとなります。どのようにプロジェクトマネジメントを実施していくかも考えなければなりません。

ステップ2では、業務フローのTo Beを作成しなければなりません。現在の業務フローでよいのか、変更しなければならないのかを考えなければなりません。

ERPなどのソリューションを導入するのでなければ、To Beを考える上で、そのベストプラクティスがどのようなものであるか、ベンチマークすることも必要になります。

このような時に、APQCのProcess Classification Frameworkが参考になります。これは、業界を超えて汎用的に業務フローがどのようになっているのかを表したものです。現在は、2005年6月に改定されたバージョン3.0が公開されています。

www.apqc.orgへ行き、英語版ですが、無料でpdfをダウンロードできます。ユーザ登録をすると、日本語版も手に入ります。

このステップで、もし社内に業務フローを書ける人材が足りない場合は、ソリューションプロバイダーへ業務フロー作成支援を発注しなければなりません。

業務フロー自体を書くツールはいろいろあります。マイクロソフトは、Visioを利用して業務フローを文書化するテンプレートを無料で公開しています。

ステップ3では、実際に文書化を行う現場担当者の教育に時間がかかります。また、作成された文書の保管、検索、バージョン管理などが必要になります。

eラーニングシステムを導入して教育コストを下げたり、文書管理システムを導入して、対策漏れやミスを減らすことが必要になります。

ステップ4では、策定した業務フローや承認フローが現場に定着しない問題が発生するかもしれません。このような場合には、ワークフローシステムを導入して業務フローを電子化することが必要になるかもしれません。

ステップ5では、開発時のテスト計画書やテスト結果が文書化されていないこともあるかもしれません。CATS（Computer Aided Test System）などを利用して再利用できるようにしておかなければなりません。

このように、日本版SOX法に対応するには、基幹業務自体も、そして、対応プロジェクトで使用するツールにもITを活用することが必要になります。

さらに、業務、システム、両方の側面でも、変更が必要になります。

業務面では、口約束や属人的な対応などあいまいなやり方が許されなくなります。対応プロジェクトの要件定義書、変更管理、テスト計画、テスト結果などすべてを文書化しなければなりません。また、要件ヒアリングの議事録なども当然残さなければなりません。

契約書類や、内容を内部統制の観点から変更しなければならないかもしれません。

運用・保守業務でも指示や結果報告などを文書化しなければなりません。サービスレベルマネジメントが必要になります。

さらに、文書が不正に作成されていないことを証明しなければなりません。

システム面では、導入したアプリケーションが正しく動作していることを証明・監査できる機能が必要になります。

また、他システムとインターフェースを通してデータのやり取りを行っている場合は、データが間違いなく受け渡しできていることを証明・監査できる機能が必要になります。

利用面で考えれば、入力時のミスや不正を未然に防止できる機能が必要になります。

さらに、企業のポリシーに合ったセキュリティ機能や冗長性をシステムに盛り込まなければなりません。