帳票の再構築にBIを使うには？

個別開発とBI内製化は、帳票の用途で使い分ける

最初に、新しい基幹システムの標準帳票で必要な業務を進められるかを確かめます。項目の並びや見た目が違っても、用途を満たせるなら、旧帳票をそのまま再現するための開発は減らせます。

標準機能で足りない帳票について、個別開発とBIを比較します。個別開発は帳票ごとにプログラムや専用処理を作る方法、BI内製化は社内担当者がBI上で抽出条件・集計・表示を作成、変更する運用です。個別開発を社内で行うことも、BIの初期構築を外部へ依頼することもできます。

売上・在庫などの社内集計は、BIで変更できる範囲を確かめる

部門別の売上実績、在庫一覧、受注残の確認など、見る人が期間や対象を変える帳票は、BIでの内製化を検討しやすい用途です。部署や期間だけが違う帳票なら、一つの画面に絞り込み条件を設ける方法もあります。

ただし、抽出条件を変えることと、売上の定義や原価の計算式を変えることは分けて管理します。利用者が自由に変えてよい部分と、全社でそろえる集計ルールを決めておく必要があります。

請求書・納品書などは、発行業務まで含めて判断する

請求書や納品書は、見た目に加え、採番、発行対象の確定、再発行、送付などの要件を確認します。まず基幹の標準機能や帳票ツールで対応できるかを調べ、不足する処理を個別開発の対象にします。

BIにも固定様式の帳票機能や帳票ツールと連携する方式があります。「BIだから対応できない」「PDFに出せるから置き換えられる」とは決めず、明細全件、改ページ、発行の手順まで試すことが必要です。

帳票一覧を見直し、作り直す対象を減らす

帳票数だけで開発量を見積もる前に、各帳票がどの業務で使われているかを調べます。画面を印刷したもの、Excelへ転記するための一覧、会議で使う集計表では、残すべき機能が異なります。

出力した後に何をしているかまで確認する

利用部門には「必要ですか」と聞くだけでなく、直近で使った場面や、帳票を受け取った後の作業を確認します。月次では使わなくても、決算期や例外対応で必要になる帳票も対象です。

使う人と用途

誰が何を確認し、その後にどんな処理や判断をするか。社外へ提出・送付するものか。

利用頻度と期限

日次、月次、年次、随時のどれか。基幹の稼働初日から必要か、後日でも業務を進められるか。

出力後の加工

Excelへの転記、他の帳票との突き合わせ、並べ替えや追記があるか。

元データと計算

取得元、抽出条件、計算式、締め時刻は何か。別の帳票と同じデータを使っていないか。

様式と保存

旧様式を維持する理由は何か。印刷、再出力、発行時点の内容保存が必要か。

廃止・統合を決めてから、再構築の方式を割り当てる

使われていない帳票は、業務責任者に確認して廃止候補にします。同じ集計を部門別に出しているなら統合を検討し、用途が重なる新基幹の標準帳票があれば置き換えます。

残った帳票を「標準機能で対応」「BIで集計・確認」「帳票ツールや個別開発で対応」に振り分けます。たとえば、同じ受注データでも、顧客へ渡す注文請書と、社内で受注残を調べる一覧では必要な機能が違います。データが同じでも、出力先まで同じ仕組みにそろえる必要はありません。

BIへ移す前に決めたいデータの受け渡し

BIで帳票を作れても、新基幹から必要なデータを取り出せなければ運用できません。画面の試作と並行して、情報システム部門と基幹ベンダーが取得方法を確認します。

取得方法と更新時刻を、基幹の設計段階で決める

データベースの参照、API、定期出力ファイルなど、利用できる経路を新基幹の仕様・契約に照らして確かめます。取得する項目、更新頻度、接続権限に加え、連携機能に別費用がかかるかも確認してください。

元データを直接参照する方式と、別の場所へ取り込んでから参照する方式では、更新のタイミングや接続先への負荷が異なります。基幹の処理を妨げないかを確かめ、必要に応じて帳票用のデータ保管先を設けます。

毎朝の受注残確認なら「業務開始までに前日分を反映」、月次資料なら「締め処理の完了後に更新」のように、必要な時刻を要件にします。画面には最終更新時刻を表示し、更新が失敗したときに誰が気付き、どの帳票の利用者へ知らせるかも決めておきます。

旧新コードの対応と、締め時点の数字をそろえる

刷新に伴って商品・取引先・部門のコードが変わる場合は、旧コードとの対応表を用意します。売上日と計上日、税込と税抜、返品・取消の扱いなども確認し、新旧の帳票で比較条件を合わせてください。

過去データを最新の部門マスターで集計すると、組織変更前の部門別実績と数字が変わることがあります。現在の組織で過去を分析する帳票と、当時の締め値を再現する帳票は、要件を分けて設計します。

締め時点の内容が必要なら、履歴を残すのか、確定結果を保存するのかを決めます。旧システムを停止した後も必要な明細や発行済み帳票については、保存対象と検索・閲覧方法まで移行計画に含めます。

初期費用に加え、変更・保守まで含めて比較する

個別開発の見積額とBIのライセンス料だけでは、費用の条件がそろいません。同じ対象帳票と利用期間で、外部へ支払う金額と社内の作業時間を並べることが比較の出発点です。

最初に作る費用

帳票設計、データ抽出・加工、接続設定、帳票や画面の作成、移行テスト。BIでもデータ整備や試作の工数を含めます。

使い続ける費用

ライセンス、サーバーやクラウド、保守契約。作成者・閲覧者の人数、配布方法、必要な出力機能で料金が変わるかを確認します。

社内で担う作業

担当者の学習、帳票作成、問い合わせ対応、更新失敗の調査、引き継ぎ。通常業務と両立できる作業量かを見積もります。

変更時の費用

組織変更、項目追加、基幹の仕様変更に伴う修正と再テスト。社内で直せる範囲と、外部支援が必要な範囲を分けます。

BI内製化を選ぶなら、試作中に社内担当者が実際に項目追加や集計条件の変更を行い、作業時間と支援が必要だった箇所を記録します。操作説明を受けただけで、以後の保守もできるとは判断しないほうが確実です。

データ接続や共通の集計ルールは専門担当者が整え、その上で業務部門が帳票を作る分担も考えられます。どこまで内製するかは、画面作成とデータ基盤の保守を分けて決めましょう。

試作から切り替えまでの進め方

大量の帳票を移行する場合も、先に代表的な帳票で難しい条件を確かめます。基幹の本稼働日だけでなく、帳票の仕様を決める期限と、旧システムを停止する期限を分けて管理してください。

1. 重要な帳票と、再現が難しい帳票を選んで試す

   頻繁に使う帳票に加え、複数データの結合が必要なもの、明細が多いもの、固定様式が厳しいものを選びます。簡単な集計表だけを試すと、後から個別開発が必要な範囲を見落とすおそれがあります。

   試作前に、必要な項目、計算式、出力形式、利用人数、更新完了時刻を決め、合否の基準を共有します。

2. 合計・明細・例外処理を、新旧で照合する

   同じ期間と対象で、件数、金額、数量を比較します。総合計だけでなく、部門別・商品別や、差が出た明細まで確認してください。返品、取消、締め後の訂正、該当データがない場合もテストに含めます。

   受入条件には、たとえば「主要な集計値が一致する、または承認した仕様差で説明できる」「必要な明細が欠けずに出力される」「決めた時刻までに更新が終わる」を設定します。旧帳票にも誤りがあり得るため、差異は元データと計算ルールへ戻って判断します。

3. 利用者の操作と、社内で保守できる範囲を確かめる

   実際の担当者が条件を指定して帳票を出し、必要な情報を確認できるかを試します。部門ごとの閲覧権限、Excel・PDFへの出力、想定人数で使ったときの応答時間も検証対象です。

   帳票を変更する人、集計ルールを承認する人、データの更新失敗に対応する人を決めます。取得元と計算式、変更履歴を記録し、作成者以外も引き継げる状態にします。

4. 移行順序と、切り替えられない場合の対応を決める

   基幹の稼働初日から必要な帳票を優先し、後から移せる分析用帳票とは期限を分けます。並行稼働できる期間には新旧の結果を照合し、切り替える帳票ごとに業務責任者が受け入れを判断します。

   未完了の帳票が残った場合の代替手順も事前に用意します。請求書などの発行を伴う帳票では、二重発行を防ぐため、どちらを正式な出力元にするかを明確にしてください。旧システムの停止は、過去データの閲覧・再出力も確認してから判断します。