まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

二重入力の工数を見積もる方法|手戻りまで数えて減らす入力を決める

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • 二重入力は転記1本ずつに分け、入力元・入力先・転記する人・件数を書き出してから、1件あたり時間×件数×頻度で月間の人時に直す
  • 入力時間だけでなく、突合・修正・問い合わせの手戻りを足した第2の数字を出すと、後工程に負担を流している転記が見える
  • どこから減らすかは、手戻りを含めた月間工数、手戻りの多さ、入力元が決まった形式かどうかの3つで決める
  • 手段はルール統一、CSV取込・出力、APIなどの連携、RPA、統合の順に準備の軽いものから検討し、使えるかどうかは自社システムの仕様と契約で確かめる
  • 提案は削減見込みと負担を時間で並べて1枚にまとめ、範囲を絞った試行で現状と同じ方法で測り直してから広げる

20代前半の日本人女性が在宅でのノートPCと外部モニターをしている場面

二重入力の工数は、自分の業務でどう見積もればよいか

月末になると同じ注文を販売管理と出荷表に打ち直し、残業が増えています。
それなのに、どこで何時間かかっているのかを説明できない。
そんなときは、二重入力を「どこから来た情報を、誰が、どこへ、何件写しているか」に分けます。
そのうえで、1件あたり時間×件数×頻度で月間の工数を出します。
そこへ突合や修正の手戻りを足すと、減らすべき入力の順番が見えてきます。
手段は、運用ルールの統一、取込・出力機能、連携、RPAの順に検討します。
削減できる時間と導入・運用の負担を1枚に並べれば、上司や情報システム部門に相談するときの材料になります。

入力元・入力先・転記する人・件数に分ける

二重入力の時間を見積もろうとして「毎日2時間くらい入力している」と答えると、数字はすぐに出ます。
ただ、そこから先には進めません。
その2時間の中には、性質の違う転記がいくつも混ざっているからです。
どの転記を減らすかを決めるには、まず作業を転記1本ずつに分けて数える必要があります。

たとえば、取引先からメールで届いた注文を、受注担当が販売管理システムに入力している職場を考えます。
受注担当は同じ内容を出荷指示用の表計算ファイルにも打ち込み、月末には経理担当が販売管理の売上を会計システムへ登録しています。
入力元はメール1通でも、転記は「メール→販売管理」「販売管理→出荷指示表」「販売管理→会計」の3本に分かれます。
担当者の感覚では「受注入力」という一つの仕事でも、減らし方は3本でそれぞれ違います。

転記1本ごとに、次の4つを書き出します。

  • 入力元:何を見て入力しているか(メール本文、FAX、紙の伝票、別システムの画面や帳票など)
  • 入力先:どのシステムやファイルへ入力しているか
  • 転記する人:誰が、どの時間帯に入力しているか
  • 件数:1日または1か月に何件入力しているか

入力元を書くときは、その情報が最初にどこで生まれたかまでさかのぼっておくと、後で手段を選ぶときに役立ちます。
出荷指示表の入力元は販売管理の画面ですが、その内容はもともと取引先のメールです。
システムの中にすでにある情報を写しているのか、外から来た情報を初めてシステムに入れているのか。
この違いで、減らせる範囲が大きく変わります。

入力している人と改善を決める人が別の職場では、この一覧がそのまま、決める側へ渡す資料の骨組みになります。
決める側が知りたいのは「忙しい」という感覚よりも、どの転記に何時間かかっているかです。
転記単位で分けておけば、後から数字を足しても、どこが増えたのかを相手が追えます。

1件あたり時間の測り方

1件あたりの時間は、思い出して答えるより実際に測ったほうが、説明に使える数字になります。
思い出した時間には、入りにくい時間があるからです。
入力の途中で画面を切り替えた時間、得意先コードを探した時間、電話で中断した後に入力を再開するまでの時間などです。
測り方は簡単で、入力元を開いてから入力先で保存するまでの開始時刻と終了時刻を、転記1本ごとに記録します。

測る範囲は、担当者数名で数日間を目安にします。
同じ転記でも人によって慣れが違い、1人だけを測るとその人の速さが職場全体の数字になってしまいます。
日にちも、通常の日だけでなく月末や繁忙期の日を含めておきます。
そうすると、件数が増えたときに1件あたりの時間が延びるかどうかも見えます。
全員を長期間測る必要はありません。
目的は、相談相手に「この程度の時間がかかっている」と根拠を示せる数字を作ることです。

注文によって明細行の数が大きく違う場合は、1件あたりではなく1行あたりで測るほうが実態に近くなります。
3行の注文と30行の注文を同じ1件として平均すると、どちらの日の作業も説明できない数字になるからです。
また、この段階では入力そのものの時間だけを測り、入力後の照合や修正は別に記録しておきます。
手戻りは次の見積もりで足すため、ここで混ぜると同じ時間を二度数えることになります。

月間の人時に直す

測った時間は、1件あたり時間×件数×頻度で月間の工数に直します。
工数の単位には人時を使います。
人時は、1人が1時間働いた作業量を1とする数え方で、2人が30分ずつ入力すれば1人時です。
件数は担当者の記憶ではなく、後から確かめられる記録から取ります。
システムの受注件数、伝票番号の連番、受信したメールの件数などが使えます。

先ほどの職場で、仮に次のような数字が測れたとします。
メールから販売管理への入力が1件4分で1日20件、月20営業日なら、4分×20件×20日で1,600分、26時間40分です。
販売管理から出荷指示表への転記が1件2分なら、同じ件数で800分、13時間20分になります。
月末に経理担当が400件を1件1分で会計システムへ登録しているなら、400分、6時間40分です。
3本を合わせると、毎月46時間40分が転記に使われている計算になります。

頻度は、毎日発生する転記と、月末にまとめて発生する転記を分けて掛けます。
月末にまとまる転記は、月全体の時間が小さくても、特定の数日に集中します。
月間の合計とは別に「どの日に何時間」も書き添えておくと、残業が増える理由の説明になります。
なお、この算出の型は自分の業務を説明するための目安であり、公的に定められた計算方法ではありません。
相手に渡すときは、測った日数と人数、件数をどの記録から取ったかを一緒に書いておきます。
そうすれば、数字の確からしさを相手が判断できます。

1通の注文メールから生まれる3本の転記(例・模式図)
メール注文が販売管理システムに入力され、その内容が出荷指示表と会計システムへ別々の人によって転記される関係1取引先からのメール注文2販売管理システム3出荷指示表と会計システム

▼ 図の内容を文字で読む
  1. 取引先からのメール注文
    • 入力元はメール1通
  2. 販売管理システム
    • 受注担当が入力する(メール→販売管理)
  3. 出荷指示表と会計システム
    • 受注担当が出荷指示表へ転記する(販売管理→出荷指示表)
    • 経理担当が月末に会計システムへ登録する(販売管理→会計)

手戻りや確認作業まで含めると、見積もりはどう変わるか

突合・修正・問い合わせの時間を足す

入力時間だけの見積もりには、転記の後に発生する仕事が入っていません。
同じ内容を別の場所へ写す以上、写し間違いが起きていないかを確かめる作業が後に続きます。
間違いが見つかれば、直す作業も加わります。
しかもその仕事は、入力した本人ではなく、出荷担当や経理担当など後工程の人が抱えていることがあります。
入力した人の時間だけを測ると、二重入力が生んでいる負担のうち、後工程の分が見えなくなります。

足す作業は大きく3つです。
1つ目は突合で、入力元と入力先の内容を照らし合わせて、一致しているかを確かめる作業です。
2つ目は修正で、誤りを見つけて入力し直したり、訂正の伝票を起こしたりする作業です。
3つ目は問い合わせ対応です。
出荷担当から「数量が注文と違う」と連絡を受け、入力元のメールを探し直して答えるような作業がこれにあたります。

この3つは発生の仕方が違うため、数え方も分けます。
全件を読み合わせる突合は毎件発生するので、入力と同じく1件あたり時間×件数で数えます。
修正と問い合わせは誤りがあったときだけ発生するので、手戻りの件数×1回あたりの時間で数えます。
1回の手戻りには、誤りに気づく、原因を調べる、関係者に連絡する、入力し直す、という複数の手間が含まれます。
そのため、1件の入力よりずっと長くなることがあります。

先ほどの出荷指示表への転記で考えます。
出荷前に全件を1件1分で突合していれば、月400分かかります。
誤りが月12件あり、1件の修正と問い合わせに20分かかっていれば、さらに月240分です。
入力だけでは13時間20分だった転記が、手戻りを含めると24時間になります。
一方、メールから販売管理への入力は、突合をしておらず、誤りの修正が月5件・1件15分程度だったとします。
この場合は、26時間40分に1時間15分が加わるだけです。
入力時間だけで比べると、出荷指示表への転記は半分ほどの重さに見えました。
手戻りまで含めると、その差は4時間ほどまで縮みます。

このように、入力のみの数字と手戻りを含めた数字の2つを並べると、どの転記が後工程に負担を流しているかが分かります。
入力のみの数字に対して手戻りの割合が大きい転記は、入力そのものを速くしてもあまり効きません。
転記をなくすか、誤りが起きにくい形に変えるほうが、効果が出やすい候補です。

手戻り率を自分の記録から数える

手戻りの多さは、他社や業界の誤り率を借りてくるより、自分の職場の記録から数えるほうが相談の材料として強くなります。
入力元の形式も担当者の慣れも職場ごとに違い、よその数字では自分の転記の重さを説明できないからです。
手戻り率は、ある期間の手戻り件数を、同じ期間の転記件数で割って出します。
先ほどの例なら、月400件の転記で12件の手戻りなので3%です。

手戻り件数の手掛かりは、すでに職場に残っていることがあります。

  • システムの修正履歴や、訂正・取消の伝票
  • 出荷後の再送や返品の記録
  • 後工程からの問い合わせメールやチャットの履歴
  • 月末の締めで差異を調べた記録

これらは手戻りそのものの記録ではありません。
1件ずつ見て、転記の誤りが原因のものだけを数えます。
取引先が注文を変更したことによる訂正は、二重入力とは別の手戻りとして分けておきます。

記録から数えるときは、誤りがどこで生まれたかも一緒に分けておくと、手段を選ぶときに役立ちます。
手書きのFAXの数字を読み違えたのか、入力先で似た商品コードを選び間違えたのか、出荷指示表に写すときに行がずれたのか。
原因によって、効く対策が違うからです。
読み違いが多いなら入力元の形式に目を向けます。
コードの選び間違いが多いなら、マスタ(得意先や商品の基本情報の一覧)や入力ルールが見直しの対象です。
行ずれが多いなら、システム間で写す工程そのものが問題になっています。

転記のあとに足す3つの作業と数え方
突合は1件あたり時間×件数、修正と問い合わせ対応は手戻りの件数×1回あたりの時間で数えるという分け方突合は1件あたり時間×件数、修正と問い合わせ対応は手戻りの件数×1回あたりの時間で数えるという分け方突合入力元と入力先を照らし合わせて確かめる作業毎件発生するので、1件あたり時間×件数で数える修正誤りを見つけて入力し直す、訂正の伝票を起こす作業誤りがあったときだけ発生するので、手戻りの件数×1回あたりの時間で数える問い合わせ対応後工程から「数量が注文と違う」と連絡を受け、入力元のメールを探し直して答える作業誤りがあったときだけ発生するので、手戻りの件数×1回あたりの時間で数える

▼ 図の内容を文字で読む
  • 突合
    • 入力元と入力先を照らし合わせて確かめる作業
    • 毎件発生するので、1件あたり時間×件数で数える
  • 修正
    • 誤りを見つけて入力し直す、訂正の伝票を起こす作業
    • 誤りがあったときだけ発生するので、手戻りの件数×1回あたりの時間で数える
  • 問い合わせ対応
    • 後工程から「数量が注文と違う」と連絡を受け、入力元のメールを探し直して答える作業
    • 誤りがあったときだけ発生するので、手戻りの件数×1回あたりの時間で数える

どの二重入力から減らすと効果が大きいか

3つの観点で並べる

転記ごとに2つの数字がそろったら、どこから減らすかを決めます。
このとき、月間工数の大きい順に並べるだけでは足りません。
工数が大きくても、減らすための準備が重い転記は、後回しにしたほうが早く成果が出ることもあるからです。
並べる観点は、手戻りを含めた月間工数、手戻りの多さ、入力元が決まった形式かどうかの3つです。

3つ目の観点は、手段を選べる幅に直結します。
入力元が別のシステムの画面や帳票なら、項目の並びも書き方も毎回同じで、データとして取り出せる可能性があります。
一方、取引先ごとに書き方の違うメールや手書きのFAXは、人が読み取って解釈しないと、入力先の項目に当てはめられません。
同じ1時間の転記でも、前者は人の手を介さない形に近づけやすく、後者は形式をそろえるところから始めることになります。

先ほどの職場に当てはめると、次のように整理できます。

  • メール→販売管理:工数は最大だが、入力元は取引先ごとに書き方が違うメール
  • 販売管理→出荷指示表:工数の半分近くが手戻りで、入力元はすでにシステムの中にある
  • 販売管理→会計:月の合計は小さいが月末に集中し、入力元はシステムの中にある

この場合、最初に手を付ける候補は、販売管理から出荷指示表への転記です。
システムの中にすでにある情報を、もう一度人が打ち直しているからです。
写す工程をなくせれば、入力も突合も手戻りもまとめて減り、取引先の協力も要りません。
会計への転記は、合計工数よりも、月末の残業を減らしたいかどうかで順位が変わります。
工数が最も大きいメールからの入力は、効果は大きくても取引先側の形式に左右されます。
そのため、別の検討として並行して進めるのが現実的です。

受注の注文書入力が課題になる場面

メールやFAXで届く注文書の入力が重い課題になりやすいことは、受注の現場を対象にした調査にも表れています。
食品の小売・卸売業で受注業務を担当する人を対象にした2023年3月の調査では、FAX・Eメール・電話で受注していると答えた90名のうち、「注文書の『手入力』に手間がかかる」を挙げた人が6割で、課題の中で最も多い回答でした1。

この数字を読むときは、対象の範囲に注意が要ります。
調査はシステムを提供する企業であるハンモックが発表したもので、IDEATECHが2023年3月6〜7日にインターネットで実施しました1。
有効回答は、食品の小売・卸売業で受注業務に携わる106名です。
課題の設問に答えたのは、そのうちFAX・Eメール・電話で受注している90名です。
二重入力全般の割合でも、ほかの業種の割合でもありません。
自分の職場が食品の受注でなければ、似た場面の参考として読むのが適切です。

この結果から読み取れるのは、外から届く注文書を人が読んで入力する作業は、受注担当者自身が手間として強く感じやすい場所だということです。
先ほどの整理でいえば、メールから販売管理への入力がこれにあたります。
この転記は入力元が自社の外にあるため、販売管理から出荷指示表への転記のように、社内の仕組みだけでは片づきません。
工数が大きいのにすぐ減らせないのはこのためです。
取引先に注文の様式をそろえてもらう、取引先側のシステムから出せるデータがあるか尋ねる、といった相手との調整を含む検討になります。
その間も、受け取った後の社内の転記を減らしていけば、外から来た注文を人が入力する回数は最初の1回に抑えられます。

3本の転記を3つの観点で見た優先順位(本文の例・模式図)
メールからの入力、出荷指示表への転記、会計への転記を、工数・手戻り・入力元の形式で見比べ、出荷指示表への転記を最初の候補とする整理メールからの入力、出荷指示表への転記、会計への転記を、工数・手戻り・入力元の形式で見比べ、出荷指示表への転記を最初の候補とする整理メール→販売管理工数は最大入力元は取引先ごとに書き方が違うメール取引先側の形式に左右されるため、別の検討として並行して進める販売管理→出荷指示表工数の半分近くが手戻り入力元はすでにシステムの中にある最初に手を付ける候補販売管理→会計月の合計は小さいが月末に集中する入力元はシステムの中にある月末の残業を減らしたいかどうかで順位が変わる

▼ 図の内容を文字で読む
  • メール→販売管理
    • 工数は最大
    • 入力元は取引先ごとに書き方が違うメール
    • 取引先側の形式に左右されるため、別の検討として並行して進める
  • 販売管理→出荷指示表
    • 工数の半分近くが手戻り
    • 入力元はすでにシステムの中にある
    • 最初に手を付ける候補
  • 販売管理→会計
    • 月の合計は小さいが月末に集中する
    • 入力元はシステムの中にある
    • 月末の残業を減らしたいかどうかで順位が変わる

運用の見直し・取込機能・連携・RPAのうち、どの状況でどれが現実的か

入力の発生元と件数で分ける

減らす手段は、準備の軽いものから順に5つが考えられます。
入力ルールや項目名の統一、既存システムのCSV取込・出力、APIなどによるシステム間の連携、RPA、システムの統合です。
この順番は、効果の大きさの順位ではありません。
準備の軽いものから検討すれば、重い手段を入れなくても済む転記を先に見分けられる、という考え方による並びです。

手段ごとに、なくせる手間の深さが違います。
入力ルールの統一は、入力そのものは残します。
そのかわり、どの項目に何を書くか迷う時間や、表記の揺れによる突合の手間を減らします。
CSV取込・出力は、CSV(項目をカンマで区切った、多くのシステムで読み書きできる形式のファイル)を使って、手で打ち込む作業をファイルの出力と取込の操作に置き換えます。
API(システム同士がデータをやり取りするために用意された窓口)による連携では、人がファイルを動かす工程もなくなります。
RPA(パソコン上の操作を、決めた手順どおりに自動で繰り返すソフトウェア)は、人の代わりに画面へ打ち込みますが、転記という工程そのものは残ります。
システムの統合は、入力先を一つにして転記をなくしますが、業務の作り直しを伴います。

表の中で判断が分かれやすいのは、入力元の形と件数です。
件数が月に十数件しかない転記では、取込の設定や連携の設計に準備をかけても、減る時間より準備の時間のほうが大きくなりがちです。
その場合は、ルールを統一して手戻りを減らすだけで十分なことがあります。
反対に、件数が多くても入力元が取引先ごとにばらばらのメールなら、CSV取込もRPAも、そのままでは入力元を読み取れません。
まず入力元の形をそろえられるかを考え、そろえられた部分から機械に渡すことになります。

先ほどの販売管理から出荷指示表への転記は、入力元がシステムの中にあり、件数も毎日まとまってあります。
そのため、取込・出力か連携が検討の中心になります。
出荷指示表が表計算ファイルであれば、販売管理から出荷に必要な項目を出力できるかどうかが分かれ目です。
出力できれば、打ち直しの代わりに、出力したデータを貼り付けるか読み込む形にできる可能性があります。
どちらが使えるかは、自社のシステムの仕様で決まります。

連携できるかの確かめ方

取込や連携が使えるかどうかは、製品の一般的な説明ではなく、自社で使っているシステムの仕様と契約で決まります。
同じ製品でも、契約している範囲や設定によって、出力できる項目が違うことがあるからです。
迷いやすいのは、「CSV取込に対応」と書かれていても、自分の転記に必要な項目がすべて取り込めるとは限らない点です。

確かめる項目は、転記1本ごとに次のとおりです。

  • 入力元のシステムから、転記している項目をCSVなどで出力できるか
  • 入力先のシステムに取込機能があり、必要な項目がすべて取込対象に入っているか
  • 得意先コードや商品コードが両方のシステムで同じか、違うなら対応表を作れるか
  • 取込時に誤りがあった行を、どう知らせ、どう扱うか
  • APIなどの接続の窓口があるか、使うために追加の契約や費用が要るか

このうちコードの対応は、見落とされやすい項目です。
販売管理では得意先を数字のコードで持ち、出荷指示表では得意先名で管理している、という状態を考えます。
この場合、データを出力できても、入力先にそのままでは入りません。
対応表を作って保守する手間が残るので、その分も後で負担として数えます。

確かめる役割は、分けると進めやすくなります。
現場担当は、転記1本ごとにどの項目を写しているかを、実際の画面や帳票を見ながら一覧にします。
情報システム部門やベンダーは、その一覧と仕様書を突き合わせ、出力・取込・接続の可否と、使う場合の条件を答えます。
項目の一覧が先にあれば、相手は「連携できますか」という漠然とした質問ではなく、具体的な項目ごとに答えられます。

RPAを使う前に業務を定型化する

RPAは、画面の操作を決めた手順でなぞる仕組みです。
そのため、手順の途中で人の判断が要る場面があると、そこでロボットは止まり、人が引き継ぐことになります。
注文書に手書きの追記がある、マスタに登録されていない商品が来た、取引先ごとに特別な値引きがある、といった例外が多い転記もあります。
そうした転記では、ロボットが処理できる件数が限られます。
止まった分を確かめて処理する仕事が、新たに生まれます。

ですから、RPAを検討する前に、手戻りの記録で見つけた例外を書き出し、判断のルールを決めておきます。
「未登録の商品は入力を保留して担当者に回す」「追記がある注文は人が入力する」のように、例外の扱いを決めておくのです。
そうすれば、ロボットに任せる範囲と人が受け持つ範囲の境目がはっきりします。
この作業は、RPAを入れなかった場合にも、担当者ごとの判断のばらつきを減らすことにつながります。

Close-up of colleagues discussing work using a laptop and notebook in an indoor office setting.
▽ 写真の出典元

もう一つ考えておきたいのは、RPAが入力先の画面に依存する点です。
システムの更新で画面の項目や配置が変わると、手順を直す必要が出ることがあります。
入力元と入力先の両方にCSVの出力・取込があるなら、画面をなぞるより先に、そちらで済まないかを確かめます。
それでも埋まらない手順にだけRPAを使うほうが、保守の手間を抑えやすくなります。

手段 なくせる手間 向く入力元 件数との関係 必要な口 例外が多いとき 準備の重さ
入力ルール・項目名の統一 迷いと表記の揺れによる手戻り 形式を問わない 少なくても効く 不要 判断ルールに書き足す 軽い
CSV取込・出力 打ち込み(ファイル操作は残る) システムから出力できる決まった形式 多いほど効く 出力と取込の機能 取込エラーを人が直す 項目とコードの対応づけが要る
APIなどの連携 ファイルを動かす工程まで システムの中にある情報 多いほど効く 接続の窓口 連携から外れた分を人が扱う 設計と保守が要る
RPA 打ち込み(転記の工程は残る) 画面操作が毎回同じになる入力元 多いほど効く 不要(画面を操作) 止まった分を人が引き継ぐ 手順の定型化と画面変更時の保守
システムの統合 入力先が一つになり転記そのもの 形式を問わない 業務全体で判断 不要 統合後の業務の中で扱う 業務の作り直しを伴う

削減できる工数と導入・運用の負担をどう比べて、提案に落とし込むか

提案シートの項目

ここまでで、転記ごとの工数と、それを減らせそうな手段の候補がそろいました。
上司や情報システム部門に相談するときは、これを1枚にまとめます。
載せる項目は次のとおりです。

  • 対象の転記(入力元・入力先・転記する人・件数)
  • 現状の月間工数(入力のみ)
  • 手戻りを含めた月間工数
  • 手段案ごとの削減見込み
  • 手段案ごとの負担(初期設定・保守・例外処理・教育)
  • 費用(見積もりを取って記入)
  • 確かめ方(試行の範囲・期間・測る項目)

削減見込みには、現状の工数をそのまま全部減らせるとは書かないほうが、相手の信頼を得やすくなります。
CSV取込に置き換えても、ファイルを出力して取り込む操作、取込エラーの確認、例外の手入力は残ります。
削減見込みは、手戻りを含めた現状の工数から、手段を入れた後に残る作業の時間を引いて出します。
残る作業を書き出しておけば、見込みの根拠を相手が一つずつ確かめられます。

負担のほうも、できるだけ時間で書きます。
初期設定にかかる時間、例外処理に毎月かかる時間、画面や項目が変わったときの保守、新しい担当者に操作を教える時間です。
削減見込みと同じ単位で並べると、毎月減る時間と毎月増える時間を差し引きで比べられます。
費用は製品や契約によって大きく違うため、一般的な相場を当てはめて書くことはできません。
見積もりを取った金額を欄に入れ、まだ取れていない場合は空欄のまま「要見積もり」と書いておきます。
そうすれば、何が決まっていないかが相手に伝わります。

シートは転記1本につき1枚にすると、決める側が手段ごとに判断しやすくなります。
先ほどの職場なら、販売管理から出荷指示表への転記を1枚、メールからの入力を1枚に分けます。
前者は社内で決められる案、後者は取引先との調整を含む案として並べます。
性質の違う案を同じ紙に混ぜると、話の早い案まで調整待ちで止まってしまうためです。

試行して実測する

削減見込みは、どれだけ丁寧に作っても見積もりです。
例外がどれだけ出るか、取込エラーの確認に何分かかるかは、実際に動かしてみるまで分かりません。
そこで、いきなり全件に広げず、取引先や品目を絞って期間を決めて試し、その間の作業時間を測ります。

測り方は、最初に現状を測ったときと同じにします。
開始時刻と終了時刻、件数、手戻りの件数と時間を、同じ記録の様式で残します。
測り方が変わると、時間が減ったのが手段の効果なのか、数え方の違いなのかが区別できなくなるからです。
試行期間には、月末のように件数が増える時期を含めておきます。
通常の日だけでは見えない例外の増え方も、そこで確かめられます。

試行が終わったら、見込みと実測を並べて判断します。
入力の時間は見込みどおり減ったのに、例外処理が想定より多かったとします。
その場合は、手段をあきらめる前に、例外のルールや入力元の形式を見直す余地があります。
逆に、残る作業がほとんど出なかった場合は、対象の取引先や品目を広げる根拠になります。
試行の結果は、次に別の転記を検討するときにも、自分の職場で実際に測った数字として使えます。

現状の測定から試行、広げる判断までの進め方
現状を測り、提案シートにまとめ、範囲を絞って試し、同じ方法で測り直して、見込みと実測を並べて判断する流れ1現状を測る2提案シートにまとめる3範囲を絞って試す4同じ方法で測り直す5見込みと実測を並べて判断する

▼ 図の内容を文字で読む
  1. 現状を測る
    • 転記1本ごとに開始・終了時刻、件数、手戻りの件数と時間を記録する
  2. 提案シートにまとめる
    • 手段案ごとに、削減見込みと負担を時間で並べる
    • 費用は見積もりを取った金額を書き、未取得なら「要見積もり」とする
  3. 範囲を絞って試す
    • 取引先や品目を絞り、期間を決める
    • 月末のように件数が増える時期を含める
  4. 同じ方法で測り直す
    • 最初と同じ記録の様式で、時間・件数・手戻りを残す
  5. 見込みと実測を並べて判断する
    • 例外処理が想定より多ければ、例外のルールや入力元の形式を見直す
    • 残る作業がほとんど出なければ、対象を広げる根拠になる

転記の一覧と工数が出そろっても、どの転記なら自社のシステム構成で取込や連携に置き換えられるかは、仕様と運用の両方を見ないと判断しにくいところです。

入力元・入力先・件数の一覧をもとに、どの転記から手段を検討するか、何を仕様書やベンダーに確かめるべきかを一緒に整理できます。無料相談で要件を整理する

要点の整理

見積もりの単位 転記を1本ずつ分け、入力元・入力先・転記する人・件数を書き出す
月間工数 1件あたり時間×件数×頻度で人時に直し、測った人数・日数と件数の出所を添える
手戻り 突合・修正・問い合わせを足した第2の数字を出し、手戻り率は自分の記録から数える
優先順位 手戻りを含めた月間工数、手戻りの多さ、入力元が決まった形式かどうか
手段の検討順 ルール統一→CSV取込・出力→APIなどの連携→RPA→統合。可否は自社の仕様と契約で確かめる
提案と検証 削減見込みと負担を時間で並べて1枚にし、範囲を絞った試行で同じ方法で測り直す
Close-up of a hand writing in a notebook beside a calculator and laptop on a desk.
▽ 写真の出典元

削減見込みは試行で測ってはじめて確かめられますが、試行の範囲や測る項目を決めるところで迷うことがあります。 対象の転記と手段案をもとに、試行で何を測り、どの結果なら広げるかの判断材料をどうそろえるかを相談できます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

二重入力の1件あたり時間は、どのくらいの期間・人数で測ればよいですか。

担当者数名で数日間を目安にし、通常の日と月末などの繁忙日を両方含めます。
1人だけを測ると、その人の慣れが全体の数字になります。
通常の日だけでは、件数が増えたときの延び方が分かりません。
担当者が1人しかいない場合は日数を増やし、件数の多い日と少ない日を分けて記録します。
目的は精密な統計ではなく、相談相手に根拠を示せる数字を作ることです。
測った人数と日数を一緒に書いておけば足ります。

手戻りの件数を記録していない場合、どう見積もればよいですか。

これから数日間測るときに、入力時間と一緒に手戻りも記録します。
突合で見つかった誤り、修正にかかった時間、後工程からの問い合わせを、その場で件数と時間だけ書き留めます。
過去の分は、問い合わせのメールやチャット、訂正の伝票など、残っている痕跡から拾える範囲で数えます。
思い出して見積もった数字を使う場合は、それが実測ではないことを明記します。
少なめの見積もりと多めの見積もりの幅で示しておけば、後で実測と置き換えやすくなります。

基幹システムにCSVの取込機能がある場合、RPAを入れる前に何を確かめればよいですか。

まず、入力先の取込機能で、転記している項目がすべて取り込めるかを仕様書で確かめます。
次に、入力元からその項目を出力できるか、両方のシステムで得意先や商品のコードが一致しているかを見ます。
取込時に誤りがあった行がどう扱われるかも確認しておくと、残る作業を見積もれます。
出力と取込で足りる転記にRPAを重ねると、画面に依存する保守が増えるだけになりかねません。
取込で埋まらない手順があるときに、その部分だけRPAを検討します。

入力する人と改善を決める人が別のとき、工数の数字はどう渡せばよいですか。

合計時間だけでなく、転記1本ごとの一覧で渡します。
入力のみの工数と手戻りを含めた工数の2つに、測った人数と日数、件数をどの記録から取ったかを添えます。
そうすれば、決める側が数字の確からしさを判断できます。
あわせて、社内だけで決められる案と、取引先やベンダーとの調整が要る案を分けておくと、決める人が誰に何を頼めばよいかが分かります。
試行の範囲と期間の案まで付けておけば、「まず小さく試す」という判断がしやすくなります。

取引先の受注システムなど、外部から来る注文は自社側でどこまで減らせますか。

取引先から届く注文の形式は、自社だけでは変えられません。
自社側ですぐにできるのは、受け取った注文を社内で何度も写さないようにすることです。
外から来た注文を入力する回数を1回にし、その後の出荷や会計への転記を取込や連携に置き換えます。
そうすれば、外部の注文に起因する二重入力は最初の1回に絞れます。
そのうえで、取引先側のシステムから注文データを出力してもらえるか、注文の様式をそろえてもらえるかを相談します。
その取引先からの注文に毎月どれだけの入力時間と手戻りがかかっているかを示すと、相手にも検討の理由が伝わります。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

> プロフィールの詳細を見る

  1. 1 出典:株式会社ハンモック(調査実施:IDEATECH)「食品業の受注業務に関する実態調査」(2023年)

画像の出典元

  1. Close-up of colleagues discussing work using a laptop and notebook in an indoor office setting./Photo by Mike Jones on Pexels
  2. Close-up of a hand writing in a notebook beside a calculator and laptop on a desk./Photo by https://kaboompics.com/ on Pexels

Photos provided by Pexels

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top