金額の境界で承認経路が切り替わらず発注が通る
承認金額の境界値の組み合わせを検証していないと、設定どおりに承認経路が切り替わらず、上位承認が必要な発注がそのまま通ってしまいます。
GENZ, Inc.
第三者検証の専門家
サプライヤー管理ツールの
第三者検証の専門家
サプライヤー管理ツールの評価と承認経路を第三者視点で検証
評価ロジックや承認ワークフローの分岐をどこまで検証するか。GENZは第三者の視点でテスト設計から関与し、検証範囲の線引きと優先順位づけを支援します。
支援事例
支援実績5,000件以上
サプライヤー管理ツールでよくある不具合
サプライヤー管理ツールの不具合は、発注・検収・支払の現場で数値の不整合となって表面化します。評価ロジックや承認ワークフローの分岐が多い分、検証で見落とした組み合わせがそのまま業務の停滞として残ります。
金額の
コード重複で仕入先が別の取引先として登録される
既存マスタからの移行でコードの重複や欠落を確認していないと、同一の仕入先が別コードで二重登録され、発注先の誤りや評価データの分散が起きます。
三者照合で数量と金額が合わず支払が滞る
発注・納品・請求の数量と金額の照合を境界値まで検証していないと、差異が検収処理で検知されず、支払の差し止めと再処理の工数が発生します。
ポータルの権限設定の不備で他社の発注情報が見えてしまう
取引先ごとのポータル権限の組み合わせを検証していないと、他社の発注情報や単価が参照できる状態が残り、取引先との信頼関係を損ないます。
重みと計算順序の設定が反映されず仕入先評価の点数がずれる
評価項目の重みづけと計算順序の設定変更を検証していないと、意図しない点数で仕入先評価が計上され、調達方針の判断を誤らせます。
残存した不具合により生じる問題
サプライヤー管理ツールで見落とされた不具合は、リリース後に発注・検収・支払の現場で表面化します。業務と取引先への波及を整理します。
静的テスト（レビュー）でおさえるべき観点
コードを動かす前に、設計書と運用の実態が食い違っていないかを文書の照合で検証します。導入・更改で見落とされやすい分岐条件や連携仕様を、ユニットテストに入る前の段段階で絞り込むための観点です。
例外の発注経路が定義書に載らないまま稼働すると、承認を経ない発注が登録でき、監査で統制不備と指摘されるおそれがあります。
購買承認の経路定義書と、金額帯・品目区分の分岐条件を照合する
承認経路の定義書に、金額帯と品目区分の分岐がすべて記載されているかを照合します。調達部門の例外運用は文書化されていないことが多く、聞き取った運用が経路定義へ反映されないまま残ります。
確認する資料
- 承認経路定義書
- 購買運用ルール
- 組織・権限一覧
コード体系の不整合を移行後に検知すると、仕入先マスタの重複登録を手作業で突合・修正する工数が発生します。
仕入先マスタ設計書と現行コード体系・桁数を照合する
仕入先マスタ設計書のコード体系と項目桁数を、現行の購買システムのマスタ定義と照合します。桁数やコード採番の食い違いは移行時にしか表面化せず、変換プログラムが重複登録を起こす原因になります。
確認する資料
- 仕入先マスタ設計書
- 現行マスタ定義書
- 移行変換仕様書
連携項目の単位差異を見逃すと、検収データと請求データの金額が一致せず、支払の誤りと再処理が発生します。
会計・ERP連携の仕様を検収・請求の項目と照合する
会計・ERP連携の仕様書が、検収・請求の項目をどの単位で受け渡すかまで定義しているかを照合します。ファイル連携とAPI定義で項目の単位に差異があると、支払で金額・数量の不整合が表面化します。
確認する資料
- 連携IF仕様書
- API定義書
- 検収・請求項目一覧
権限の粒度が取り決めより粗いまま公開すると、取引先が他社の発注情報を閲覧でき、取引関係の信頼を損なうおそれがあります。
権限ロール定義書と、取引先ごとの公開範囲の運用取り決めを照合する
権限ロールの定義書と、取引先ごとの公開範囲の運用取り決めを照合します。ポータルは複数の取引先が同じ画面群を利用する構成のため、ロールの粒度が粗いと、他社の発注情報が閲覧できる状態が残ります。
確認する資料
- 権限ロール定義書
- 運用取り決め書
- 取引先一覧
算式と運用の差異を受け入れテストまで持ち越すと、評価結果の手戻りが発生し、リリース判断の日程に影響します。
仕入先評価の算式と調達部門の評価項目・重みを照合する
仕入先評価の算式が、調達部門の評価項目と重みづけの運用と一致しているかを照合します。計算順序を仕様書で確認していないと、設定変更後の評価結果についてベンダーとの認識の差異が残ります。
確認する資料
- 評価算式仕様書
- 評価項目一覧
- 重みづけ定義書
- 現行評価運用メモ
動的テストの設計・実行のポイント
評価計算から会計連携まで、工程ごとに確認する対象と到達点を分けて設計します。この切り分けが説明できる検証範囲の前提です。
STEP 01
ユニットテスト計算順序と境界値を仕様書で確認します
どう確かめるか
ユニットテスト：算出と判定を境界値と同値分割で確かめる
評価ロジックの計算順序と重みづけの設定について、境界値と同値分割でテスト項目を設計します。重みの合計が変わる境界や端数処理の位置を項目として残し、算出結果と判定の正しさを検証します。
- 01評価項目の重みづけと計算順序を設定仕様書と照合します
- 02境界値と同値分割で算出結果の正しさを検証します
- 03端数処理と判定ロジックの期待値を項目書へ反映します
OUTPUT境界値を含む算出結果
STEP 02
統合テスト連携定義の整合を突合で確認します
どう確かめるか
統合テスト：ポータル入力から請求・会計連携までの連動を確認
取引先のポータル入力から発注・検収・請求を経て会計・ERP連携まで、ファイル連携とAPI定義でデータの整合を確認します。継ぎ目でコード体系や桁の不整合が起きていないかを突合します。
- 01ポータル入力から発注・検収までの連動を確認します
- 02請求データと会計連携のファイル・API定義を突合します
- 03マスタのコード体系と桁の整合を連携先と確認します
OUTPUT連携データの突合結果
STEP 03
システムテスト移行データで業務を通しで確認します
どう確かめるか
システムテスト：移行データで見積もりから支払反映までを通す
既存の仕入先マスタから移行したデータで、見積もり取得から発注・検収・支払反映までを業務手順どおりに通します。コード体系の差異が後工程の帳票に影響しないことを確認します。
- 01移行した仕入先マスタで見積もり取得を実施します
- 02発注・検収から支払反映までを業務手順で通します
- 03締め処理に影響する不整合がないかを確認します
OUTPUT移行データの通し結果
STEP 04
受け入れテスト運用ルールの例外を記録に残します
どう確かめるか
受け入れテスト：運用ルールに沿って例外処理とエラー発生を確認
締め時刻や再送の運用規定に沿って、例外処理とエラー発生パターンを意図的に発生させて検証します。取引先の操作と設定不備を切り分けられるよう、発生条件と表示を記録に残します。
- 01運用ルール上の例外運用をシナリオへ反映します
- 02エラー発生パターンを意図的に発生させて検証します
- 03発生条件と画面表示を証跡として記録します
OUTPUT例外処理の動作記録
GENZが代行するサプライヤー管理ツールのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 評価と承認の分岐を網羅する検証範囲の基準が決まる
- 調達部門の工数を削らず第三者の視点でテスト設計と実行を任せられる
- 検証範囲と結果を業務影響に沿った報告書として受け取れる
- 残期間に合わせた優先順位づけで未検証の範囲を記録に残せる
検証範囲の設計から報告まで担うGENZの支援
評価ロジックと承認ワークフローの分岐をどこまで検証に含めるか、発注側だけでは線を引きにくい範囲があります。GENZはテスト設計の段階から入り、検証範囲の決定から報告書の作成までを一貫して担います。
評価と承認の分岐からテスト設計を起こす
サプライヤー評価の計算順序や重みづけの設定、承認ワークフローの分岐条件を洗い出し、分岐の網羅性を基準にテスト項目を設計します。
取引先ポータルから会計連携までを検証
取引先がポータル経由で納期回答や請求データを提出する構成では、取引先を巻き込む確認を最小限に抑え、接続と業務データの整合を検証します。
どちらが主導の体制でも入って伴走
発注側主導でテスト計画から担う形でも、ベンダー主導のテスト結果をレビューする形でも、既存の推進体制とQA配置に合わせて入ります。
検証済みと未検証を分けて報告する
検証した範囲と未検証の範囲を分け、残存不具合の業務への影響も報告書へ記載します。リリース可否の判断と監査対応に使える形でお渡しします。
ご相談から納品までの流れ
ヒアリング・設計と見積もり・テスト実行・報告の順で進め、工程の残期間に合わせて検証範囲を調整します。
ヒアリング：構成と工程、残期間を確認
システムの構成と工程、残期間を確認し、検証範囲の前提を整理します。
テスト設計と見積もりの優先順位
検証範囲に優先順位を付け、テスト設計と見積もりを提示します。
テスト実行と不具合共有
テストを実行し、不具合票を起票して随時共有します。
報告書の納品と再確認
検証済みと未検証を分けた報告書を納品し、結果を再確認します。
まずは検証範囲の整理からご相談ください
サプライヤー管理ツールの検証範囲と優先順位をGENZへご相談ください
お打ち合わせでは、現行の要件と残期間をもとに、サプライヤー管理ツールの検証範囲の決め方と優先順位、必要工数を整理します。回帰テストの要否も含め、役員報告に使える形でお渡しします。