Excel出荷指示を、WMSを入れずにWebアプリへ置き換える手順

Excelで管理している出荷指示は、関数の崩れや同時編集によるファイル破損、担当者ごとの書式の違いが積み重なり、件数が増えるほど運用の限界が早まります。WMSを導入するほどの規模ではない場合、Webアプリへ置き換えることで、入力ルールを統一しながら費用を抑える選択肢があります。この記事では、置き換えを検討する際の確認事項から、移行期間の運用、定着までの手順を順番に整理します。

置き換える前に確認すること

まず、今のExcel運用がなぜ限界に近づいているのかを具体的に確認します。同時に開いている人数、1日の出荷指示件数、関数や条件付き書式が崩れた回数、ファイルの受け渡しに使っている手段（メール添付、共有フォルダなど）を書き出します。件数が少なく、同時編集もほとんど発生していない場合は、Excelの運用ルールを整えるだけで解決することもあります。置き換えが必要かどうかは、この確認の結果で判断します。

例えば、1日の出荷指示件数が30件程度で、担当者が1名しか編集しない運用であれば、ファイルの保管場所と命名ルールを決めるだけでも、関数崩れや同時編集によるトラブルは大きく減ります（仮の例です）。件数が増えてきた、または複数名が同時に編集する機会が増えてきたタイミングが、置き換えを検討する目安になります。

現状の出荷指示の流れを書き出す

次に、出荷指示が作られてからピッキングが始まるまでの流れを書き出します。確認する項目は、入力元（受注データ、モールの管理画面など）、転記先、承認が必要かどうか、承認者、出荷指示を締める時刻です。この流れを書き出すと、Webアプリに持たせるべき機能と、持たせなくてよい機能の線引きができます。

Webアプリに持たせる最小機能を決める

最初から全部の機能を持たせようとすると、開発範囲が広がり費用もかさみます。最小限必要な機能は、出荷指示の入力フォーム、一覧表示、ステータスの変更（指示済み・ピッキング中・完了など）、商品名や受注番号での検索です。Excelでできていた自由な書式の入力や、セルの色分けのような表現は、Webアプリでは別の方法（ステータスのラベル表示など)に置き換えます。印刷してピッキングリストとして使う運用がある場合は、印刷用のレイアウトも最小機能に含めておく必要があります。

データの持ち方を決める

Excelは1つのセルに複数の情報を入れたり、行を自由に追加・削除できたりしますが、Webアプリでは1件の出荷指示を1つのデータとして持たせ、変更履歴を残す形にします。これにより、誰がいつ何を変更したかが残り、トラブル時の確認がしやすくなります。項目は出荷指示番号、受注番号、商品、数量、出荷予定日、ステータス、担当者程度に絞り、Excelにあった備考欄のような自由入力は、入力ルールを決めたうえで最小限残します。

項目を決める段階で、将来増やす可能性のある項目（温度帯、配送会社、梱包形態など）があれば、そのことを設計者に伝えておきます。後から項目を追加する前提があるかどうかで、データの持ち方の設計が変わるためです。

移行期間の運用を決めておく

置き換えの初期は、ExcelとWebアプリを並行して運用する期間を設けることをPTは勧めます。並行期間を設けず一気に切り替えると、入力ミスや操作に慣れていないことによる出荷遅延が発生しやすくなります。並行期間中に、Webアプリ側でエラーや使いにくい点が出た場合に、Excel側の運用に戻す手順もあらかじめ決めておきます。

定着に必要な体制

Webアプリに切り替えた後、入力ルールを守ってもらうための周知と、エラーが起きたときの問い合わせ先を決めておく必要があります。現場の担当者が操作に迷ったときに誰に聞けばよいかが決まっていないと、結局Excelに戻ってしまうことがあります。導入直後の2週間程度は、問い合わせ対応の担当者を固定しておくと定着が早まります。

周知の際は、操作手順だけでなく「なぜExcelから置き換えるのか」という理由も合わせて伝えておくと、現場の納得感が上がります。理由が伝わっていないと、単に操作が増えただけと受け取られ、協力が得られにくくなります。

移行でよくある失敗パターン

Webアプリへの置き換えで現場の運用が崩れる場合、原因のパターンはいくつかに絞られます。1つ目は、Excelでできていた自由な入力（セルの色分け、補足メモの自由記入など）をそのまま再現しようとして、画面の設計が複雑になり開発期間が延びるパターンです。2つ目は、並行運用の期間を設けずに一気に切り替え、操作に慣れていない担当者が入力を誤って出荷遅延につながるパターンです。3つ目は、問い合わせ先を決めずに運用を始め、現場が自己判断でExcelに戻ってしまうパターンです。いずれも、事前に「何を諦めて、何を残すか」を決めておくことで避けられます。全部の機能を移そうとせず、出荷指示という業務の核になる部分だけをWebアプリに持たせる判断が、移行を成功させる分かれ目になります。

本開発まで広げる判断基準

Webアプリで運用を始めた後、対応する拠点やモールが増えたり、在庫システムとの連携が必要になったりした場合は、本開発への切り替えを検討します。判断の目安は以下のとおりです。

項目	社内の簡易運用で続けられる目安	外部に本開発を相談する目安
出荷指示件数	1日100件程度まで	件数が増え続けている、または拠点が複数ある
連携先	連携なし、または手動での反映	在庫システムやモールAPIとの自動連携が必要
利用者数	数名の固定メンバー	拠点をまたいだ多人数での利用
変更履歴の要件	現状の記録で十分	監査や取引先への報告のため厳密な履歴管理が必要

外部に依頼する場合の進め方

Webアプリへの置き換えを外部に依頼する場合も、最初から全機能の仕様を固めて発注する必要はありません。まず現状の出荷指示の流れと、持たせたい最小機能の案を自社で書き出し、その資料をもとに1テーマとして着手できる範囲を相談するほうが、要件が膨らみにくくなります。実際に動く画面を早い段階で確認しながら、入力項目や画面構成を調整していく進め方のほうが、完成後に「現場で使いづらい」という手戻りを減らせます。最初の画面ができた時点で、実際に出荷指示を数件分入力してもらい、現場の担当者からフィードバックを得る工程を挟むことをPTは勧めます。

あわせて読みたい記事として、「受注〜出荷のどこから自動化するか。費用対効果が高い着手順序の決め方」と「外注で失敗しない発注書の書き方。悪い例と良い例」も参考にしてください。

PT に相談するなら

Webアプリへの置き換えを1テーマとして進めたい場合、PT WORKS（30万円〜、税込33万円〜）で業務フローの整理から約5時間の簡易実装まで進められます。拠点をまたいだ連携や、モールAPIとの接続まで必要な場合は、PT BUILD（個別見積）での本開発を検討します。料金は参加人数、テーマ数、事前調査の量、開発範囲で変わります。出張を伴う場合の交通費・宿泊費は実費です。

5つの質問で概算を見る、または資料請求で検討に使える資料を受け取れます。