SAP Concur導入で失敗しないための要件定義では、機能一覧を確認するだけでなく、自社の経費精算・請求書処理・出張管理の業務を、誰が、どの条件で、どのシステムと連携して行うかまで具体化します。
特に重要なのは、現行業務の整理、対象範囲の確定、承認ルール、会計・人事システムとの連携、例外処理、導入後の運用体制です。これらを曖昧にしたまま設定や開発へ進むと、導入後に手作業や追加変更が増える原因になります。
SAP Concurの要件定義で最初に決めること
最初に決めるのは「どの機能を使うか」ではなく、どの業務上の問題を解決するために、どこまで対象にするかです。
1. 導入対象の業務と範囲
SAP Concurには、経費精算、請求書処理、出張に関する管理など、複数の業務領域があります。自社が利用する領域と、今回の導入対象外とする領域を明確に分けます。
- 従業員の経費申請・精算
- 法人カードの利用データ取り込み
- 請求書の受付・承認・支払い処理
- 出張の申請・予約・精算
- 会計システムへの仕訳連携
- 人事システムからの従業員情報連携
たとえば、経費精算だけを対象にするのか、請求書処理や出張管理も同時に扱うのかで、必要な業務設計や関係部署が変わります。「将来対応する機能」と「初回導入で必ず対応する機能」を分けておくと、要件が広がりすぎるのを防げます。
2. 導入目的と評価指標
導入目的は、「ペーパーレス化」や「効率化」といった表現だけで終わらせず、測定できる状態にします。
| 目的 | 要件定義で具体化する内容 |
|---|---|
| 処理を早くする | 申請から承認、支払い、会計計上までのどこを短縮するか |
| 入力ミスを減らす | どの項目を自動取得・必須入力・選択式にするか |
| 内部統制を強化する | 誰が何を確認し、どの条件で差し戻すか |
| 運用コストを下げる | 経理担当者の手作業をどこまで減らすか |
導入後に成功したか判断できるよう、処理日数、差し戻し件数、手入力項目数、未精算件数など、確認可能な指標を決めておきます。導入前の現状値を記録しておくと、導入後との比較がしやすくなります。
現行業務を整理してから要件を決める
現行業務を整理せずにSAP Concurの設定を始めると、不要な手順までシステムに再現したり、部門ごとの例外を見落としたりします。まず申請から会計処理までの流れを可視化します。
確認する業務の流れ
- 従業員が経費や請求書の情報を準備する
- 申請または登録を行う
- 上長や経理部門が内容を確認する
- 必要に応じて差し戻しや修正を行う
- 承認済みデータを支払い・会計処理へ回す
- 証憑や処理履歴を保管し、問い合わせに対応する
各工程について、担当者、入力項目、判断条件、利用する帳票やシステム、処理期限を整理します。業務フローは通常のケースだけでなく、差し戻し、代理申請、承認者不在、退職者の未精算、金額超過などの例外も含めて確認します。
部門ごとの違いを一覧にする
本社、営業部門、工場、海外拠点などで運用が異なる場合は、部門別の違いを表にします。部門ごとに異なるルールをすべて個別設定すると、運用が複雑になる可能性があるため、全社共通化できる部分と、例外として残す部分を分けます。
- 申請できる費目
- 承認者と承認段階
- 金額上限
- 利用できる法人カード
- 会計科目や部門コード
- 証憑の提出方法
- 締め日と支払い日
失敗を防ぐ承認ルールの要件定義
承認ルールは、「上長が承認する」といった抽象的な書き方では不十分です。誰が、どの条件で、何段階承認するのかを条件分岐として整理します。
承認条件を具体化する
次のような条件を組み合わせ、申請から最終承認までの流れを定義します。
- 申請者の所属部門
- 申請者の役職や職位
- 費目
- 申請金額
- 利用したプロジェクトやコストセンター
- 国内取引か海外取引か
- 法人カード利用か個人立替か
- 規定外の申請かどうか
たとえば、一定金額を超えた場合だけ部門長の承認を追加する、特定の費目は経理確認を必須にする、といった形です。条件を文章だけでなく、分岐図や一覧表でも示すと、設定担当者との認識違いを減らせます。
承認者が不在の場合も決めておく
承認者の異動、休職、長期出張、退職などが発生したとき、申請を止めない仕組みが必要です。
- 代理承認者を誰にするか
- 代理設定を誰が登録・解除するか
- 代理期間をどう管理するか
- 承認者が未登録の場合の連絡先
- 申請が一定期間止まった場合の確認方法
人事異動の情報を人事システムから連携する場合も、連携の反映タイミングと、緊急時の手動対応を定義しておきます。
入力項目と証憑の要件を決める
入力項目は多ければよいわけではありません。経理処理や分析に必要な項目を残し、申請者に不要な入力を求めない設計にします。
入力項目を3つに分類する
- 必須項目：入力がないと会計処理や承認ができない項目
- 条件付き項目：特定の費目や金額の場合だけ必要な項目
- 任意項目：分析や補足に使うが、未入力でも処理できる項目
費目、取引日、金額、取引先、部門、プロジェクト、税区分、支払方法など、会計連携に必要な情報を確認します。ただし、必要項目は自社の会計処理や管理方針によって変わるため、既存の会計システムで要求される項目と照合して決めます。
証憑の扱いを決める
領収書や請求書などの証憑については、提出方法だけでなく、提出が必要な条件と、提出後の確認担当者を決めます。
- どの取引で証憑を必須にするか
- 画像やPDFなど、どの形式を受け付けるか
- 証憑がない場合の申請方法
- 原本の保管が必要か
- 不鮮明な証憑を誰が確認するか
- 重複した証憑や同一取引をどう扱うか
証憑の保存や電子取引に関する扱いは、企業の運用や適用される法令・制度によって確認が必要です。システムの機能だけで判断せず、経理・法務などの担当部署を交えて決めます。
会計・人事・カードなどの連携要件を明確にする
SAP Concur単体の要件だけでなく、周辺システムとのデータ連携を先に定義することが重要です。連携項目、方向、頻度、エラー時の対応が曖昧だと、導入後に手作業が残ります。
| 連携先 | 主な確認事項 |
|---|---|
| 会計システム | 勘定科目、税区分、部門、プロジェクト、仕訳形式、連携タイミング |
| 人事システム | 従業員、所属、役職、上長、在籍状況、異動情報の反映方法 |
| 法人カード | 利用明細の項目、取り込み頻度、申請との照合方法、未照合時の処理 |
| 銀行・支払い関連システム | 支払い対象データ、支払日、振込情報、処理結果の戻し方 |
連携エラー時の運用を決める
正常時のデータ連携だけでなく、エラーが起きたときの責任者と復旧手順を決めます。
- エラーを最初に確認する担当者
- エラー内容を通知する方法
- 修正するデータの管理場所
- 再連携の手順
- 締め日までに復旧できない場合の代替処理
- 同じエラーを再発させないための原因分析方法
連携仕様書には、項目名だけでなく、データ形式、桁数、必須・任意、コード体系、未設定時の扱いまで記載します。
標準機能で対応する範囲と追加対応を分ける
失敗を避けるには、要望をすべて個別開発で実現しようとせず、標準機能で対応する業務、運用を見直して対応する業務、追加対応が必要な業務を分けます。
| 分類 | 判断の考え方 |
|---|---|
| 標準機能で対応 | 既存の業務を大きく変えずに、設定で実現できる |
| 運用変更で対応 | 業務ルールを簡素化・統一すれば追加開発を避けられる |
| 追加対応を検討 | 法令、会計、内部統制などの理由で自社固有の処理が必要 |
個別要望を採用する場合は、必要性だけでなく、開発費用、導入期間、将来の保守、担当者変更時の引き継ぎやすさも比較します。特定の担当者しか理解できない仕組みは、導入時に動いても長期運用で負担になりやすい点に注意が必要です。
テスト要件まで要件定義に含める
テストを「システムが動くか」の確認だけにすると、実際の業務で起きる例外を見落とします。要件定義の段階で、どの業務シナリオを合格とするかを決めます。
最低限確認したいテストシナリオ
- 通常の経費申請から承認・会計連携まで
- 金額に応じて承認段階が変わる申請
- 証憑がない、または不鮮明な申請
- 規定外の費用を申請した場合
- 申請の差し戻しと再申請
- 承認者が不在の場合
- 法人カード明細と申請の照合
- 人事異動後の承認経路
- 会計連携エラーからの再処理
- 退職者や異動者に未処理データがある場合
各シナリオには、入力条件、操作する人、期待する承認経路、作成されるデータ、エラー時の結果を記載します。テスト担当者だけでなく、経理、現場の申請者、承認者、情報システム部門が確認すると、部門ごとの見落としを減らせます。
導入後の運用体制も先に決める
導入後に問い合わせやルール変更が発生するため、運用担当者を決めずに本稼働すると、問題が現場や導入担当者に集中します。
- 利用者からの問い合わせを受ける窓口
- マスタを登録・変更する担当者
- 承認ルールを変更できる担当者
- 連携エラーを確認する担当者
- 月次・年次の締め処理を行う担当者
- 利用状況や処理遅延を確認する責任者
- 仕様変更や制度変更を検討する会議体
問い合わせ対応では、「操作方法の質問」「社内規程の確認」「データ連携の障害」「権限やマスタの変更」を分けると、適切な担当者へ振り分けやすくなります。
要件定義書に残すべき項目
合意した内容は、後から確認できる形で文書化します。口頭の合意だけで進めると、設定やテストの段階で認識が分かれます。
- 導入目的と対象範囲
- 対象となる会社、部門、利用者
- 現行業務と導入後の業務フロー
- 申請項目と必須条件
- 承認経路と条件分岐
- 費目、勘定科目、部門などのマスタ方針
- 会計・人事・カードなどの連携仕様
- 証憑の提出・確認・保管ルール
- 権限とデータ閲覧範囲
- 例外処理と手動対応
- テストシナリオと合格基準
- 導入後の運用担当者と問い合わせ窓口
- 未決事項、前提条件、決定期限
特に「未決事項」を別に管理することが大切です。決まっていない内容を要件として扱わず、誰がいつまでに決めるかを明記します。
要件定義の完了前に確認するチェックポイント
設定や開発へ進む前に、次の項目を確認すると、導入後の手戻りを抑えやすくなります。
- 導入対象と対象外の業務が明確になっている
- 通常処理だけでなく、差し戻しや承認者不在などの例外を定義している
- 承認者、承認条件、代理承認の扱いが決まっている
- 会計・人事・法人カードとの連携項目とエラー対応が決まっている
- 標準機能、運用変更、追加対応の区分が合意されている
- 証憑の提出・確認・保管方法を確認している
- テストシナリオと合格基準がある
- 導入後の問い合わせ窓口と運用担当者が決まっている
- 未決事項と決定期限を一覧で管理している
SAP Concur導入で失敗しないための要件定義は、機能を多く盛り込むことではありません。現行業務と導入後の業務を比較し、承認・連携・例外処理・運用体制まで合意することが重要です。
まずは対象業務の流れを図にし、現場・経理・人事・情報システムなど関係者ごとの要望と判断条件を一覧化してください。そのうえで、標準機能で対応する範囲と、運用変更または追加対応が必要な範囲を決めると、現実的な導入計画につなげやすくなります。
