今回は、Step 2の業務フローの作成に入ります。
Step 1で特定した業務範囲を実際にフローとして文書化するのが目的です。しかし、プロジェクト自体の目的は、財務諸表の信頼性を確保することです。
このステップで作成された成果物をインプットとして、Step 3でリスク対応を考えます。従って、業務フローは、中間成果物であるということができます。
このステップは、皆さんも日頃のプロジェクトで行っているでしょうから、詳細は必要ないと思います。
フローを書く前に、業務を分類し、
大項目：業務プロセス名
中項目：業務名
小項目：処理内容
のような形で、その業務の目的、インプット、アウトプット、具体的処理内容をまとめていきます。これを業務記述書としてまとめます。
業務が標準化されていなければ、非常に多くのフローを作成しなければなりません。しかも、連結対象関係会社すべてにわたります。
既に米国SOX法に対応したある大手製造業の経理部長さんによると、子会社を含め、約2,000もの業務フローを作成したそうです。
こんなに作成すれば、ここで力が尽きてしまいます...
業務フローの作成は、現場に任せるとして、IT部門としては、この段階で、何をしなければならないでしょうか？
業務フロー作成のお手伝い？
いえいえ、そんな甘いものではありません。
作成される業務フローに対して、ITでどのような対応をしているかを文書化しなければなりません。
これをIT業務処理統制と呼びます。
この文書は、使用しているシステム毎に必要になります。プラットフォームが異なれば、別文書が必要になります。
具体的には、データフローを始め、要件定義、設計書、そのシステムのテストシナリオ、テスト結果などが必要になります。
これは、業務を支えるITとして、処理が正しく行われていることを説明するのが目的です。
自社開発したシステムで、10年も使用しているものがあれば、これらの文書を揃えるのは、並大抵の作業ではすみません。また、システムの改修履歴も必要になります。
特に2007年問題を真近に控え、切実な問題として対応しなければならない企業にとっては...
ERPなどのパッケージを使用している場合は、基本的な部分の説明責任は、ソフトウェアベンダーが行わなければなりませんが、アドオンなどの開発を行っている部分についての説明責任は、ユーザ側で行わなければなりません。
上記の大手製造業の経理部長さんとは、先日、ある内部統制のセミナーでお会いしました。この企業は、約10年前にSAP R/3を導入しています。その時のプロジェクト仲間でした。10年ぶりの再開です。
経理部長さん曰く、
監査法人の若手が来て、「R/3のカスタマイズ定義書を見せて欲しい。」（注：カスタマイズとは、パラメータ設定のこと）
経理部長「そんなものはない！そこにシステムがあるから、ログインして確認してくれ。」
導入プロジェクト当時、要件定義書は作成したものの、カスタマイズ定義書なんて、システムを見れば分かるから、無駄な作業は止めましょう、と決定しました。
何とか、それで監査は通ったのですが、これからはどうなるか分かりません。
私が担当した導入プロジェクトでは、ほとんど、カスタマイズ定義書は作成していません...
心配です。
コメントする