在庫管理システムは、必ずしも最初から高額なシステムを導入する必要はありません。
商品数が少なく、利用者も限られ、入出庫の流れが単純であれば、Excelを正しく設計するだけでも十分な場合があります。
Excelでは管理が複雑になってきたものの、利用者が少なく、社内を中心に運用するのであれば、Accessが適しているケースもあります。
一方で、
- 複数人が同時に操作する
- 複数倉庫・店舗で在庫を共有する
- バーコードやQRコードを利用したい
- 棚卸しに長時間かかる
- 在庫数が合わない
- POSやECと連携したい
- 販売管理や基幹システムと連携したい
- 作成した担当者しかシステムを直せない
といった状態になると、ExcelやAccessだけで運用を続ける負担は大きくなります。
重要なのは、
- 「ExcelかWebか」
- 「自作か外注か」
という二択で考えないことです。
現在の仕組みについて、
- 残すもの
- 直すもの
- なくすもの
- システム化するもの
を整理し、自社に必要な方法を選ぶことが大切です。
この記事では、法人の在庫管理担当者、情報システム担当者、現場責任者、経営者に向けて、Excel、Access、Webシステム、SaaSによる在庫管理の違い、自作する場合の設計方法、運用上の限界、外注へ切り替える判断基準まで詳しく解説します。
最終的な目的は「Excelを使い続けるか」「Accessへ移すか」を決めることではありません。
自社の在庫管理を、最も無理なく、長く使える方法で改善することです。
在庫管理システムを自作する前に確認したい目的と考え方
在庫管理システムを自作するとき、最初にExcelの関数やAccessのフォームを作り始めるのはおすすめできません。
最初に確認するべきなのは、
- 何を管理したいのか
- 現在どこに問題があるのか
です。
例えば「在庫管理を効率化したい」という要望だけでは、必要なシステムは決まりません。
- 現在庫だけ分かればよいのか。
- 入庫・出庫の履歴まで必要なのか。
- 棚卸しを短縮したいのか。
- 倉庫内の保管場所まで管理したいのか。
- 発注点を管理したいのか。
- 複数拠点で在庫を共有したいのか。
目的によって必要な仕組みは変わります。
現在のExcelが複雑だからといって、必ずWebシステムにする必要はありません。
反対に、Excelで作れるからという理由だけで、Excelを業務システムとして使い続けることが適切とも限りません。
重要なのは、
作れるかではなく、継続して安全に運用できるか
です。
在庫管理の目的は「在庫表を作ること」ではない
在庫管理の目的は、一覧表をきれいに作ることではありません。
必要な商品、部品、原材料を必要なタイミングで確保しながら、欠品と過剰在庫を減らし、現場の作業負担を抑えることです。
例えば欠品が多い会社では、
- 現在庫
- 発注点
- 発注残
- 入荷予定
- 販売実績
- 使用実績
などを確認する必要があります。
過剰在庫が問題であれば、
- 長期間動いていない在庫
- 在庫回転
- 保管場所
- 滞留在庫金額
などの把握が重要になります。
棚卸差異が多い場合は、
- 入庫履歴
- 出庫履歴
- 返品
- 廃棄
- 在庫移動
- 棚卸差異
- 作業担当者
などを記録し、差異の原因を追える仕組みが必要です。
つまり、自作を始める前に、
「現在、最も解決すべき在庫管理上の問題は何か」
を決めることが重要です。
最初に現在の業務フローを確認する
システムを作る前に、商品がどのように動いているかを確認します。
一般的には、
入荷 → 検品 → 入庫 → 保管 → 在庫移動 → ピッキング → 出庫 → 出荷 → 返品 → 棚卸し
という流れがあります。
企業によっては、
- 製造投入
- 完成品入庫
- 廃棄
- サンプル使用
- 店舗間移動
- 倉庫間移動
なども発生します。
現在、
- 誰が
- いつ
- 何を
- どこへ
入力しているのかを確認します。
例えば、
倉庫担当者が紙へ記録 → 事務担当者がExcelへ入力 → 営業担当者が別Excelへ入力
という状態なら、同じ情報を複数回入力しています。
この状態で新しいExcelを作っても、根本的な二重入力はなくなりません。
自作でも外注でも、まず業務自体を整理することが重要です。
在庫管理で最低限必要になる基本機能
一般的な在庫管理で必要になる機能を整理すると、次のようになります。
| 機能 | 主な内容 | 必要になる場面 |
|---|---|---|
| 商品・品目マスタ | 商品コード、商品名、分類、単位 | 基本となる商品情報 |
| 倉庫・保管場所 | 倉庫、エリア、棚 | 保管場所を管理 |
| 入庫 | 商品、数量、日付、入庫先 | 在庫が増える |
| 出庫 | 商品、数量、日付、出庫先 | 在庫が減る |
| 在庫一覧 | 現在庫を表示 | 在庫照会 |
| 入出庫履歴 | 数量変動の履歴 | 差異原因を追跡 |
| 在庫移動 | 倉庫間・棚間移動 | 複数保管場所 |
| 棚卸管理 | 実在庫と帳簿在庫を比較 | 在庫精度確認 |
| CSV | データ取込・出力 | Excel等との連携 |
| 帳票 | 在庫一覧・棚卸表等 | 社内外の資料 |
| 権限管理 | 利用者ごとの操作範囲 | 複数人利用 |
| バーコード | 商品・棚コードの読取 | 入出庫・棚卸効率化 |
| ロット・期限 | ロット・賞味期限等 | 食品・部品等 |
| 外部連携 | POS、EC、販売管理 | 二重入力を減らす |
最初から全機能を作る必要はありません。
現在必要な機能と、将来必要になる機能を分けることが重要です。
在庫数を直接書き換えるのではなく、履歴から管理する
小規模なExcel在庫表では、
商品A 在庫100個
という数値を担当者が直接変更するケースがあります。
簡単ですが、後から、
「昨日120個だったものが、なぜ100個になったのか」
が分からなくなります。
業務として在庫を管理する場合は、
- 入庫
- 出庫
- 返品
- 廃棄
- 在庫移動
- 棚卸調整
などの履歴を記録し、その結果として現在庫を把握する設計が基本です。
例えば、
前日在庫100 ＋入庫30 －出庫20 －廃棄2 ＝現在庫108
という考え方です。
数量だけではなく、
なぜ在庫が増減したのか
を残します。
これによって、棚卸しで差異が発生したときにも原因を確認しやすくなります。
Excel・Access・Web・SaaSのどれを使うべきか
在庫管理には複数の方法があります。
| 比較項目 | Excel | Access | SaaS | Webシステム |
|---|---|---|---|---|
| 始めやすさ | 高い | 中程度 | 高い | 開発が必要 |
| 初期費用 | 低い | 低〜中 | 比較的低い | 中〜高 |
| 複数人利用 | 工夫が必要 | 少人数向け | 対応しやすい | 対応しやすい |
| 複数拠点 | 不向きになりやすい | 構成次第 | 対応しやすい | 対応しやすい |
| 独自項目 | 自由 | 自由 | 制限あり | 自由度が高い |
| 独自帳票 | 作りやすい | 作りやすい | 製品次第 | 対応可能 |
| 外部連携 | CSV中心 | CSV等 | 製品次第 | 開発可能 |
| 保守 | 社内担当者 | 社内・外部 | ベンダー | 開発会社等 |
| 向いているケース | 小規模 | 小〜中規模 | 標準業務 | 独自業務 |
ExcelからWebシステムへ一気に移行する必要はありません。
現在の業務規模と将来計画に応じて判断します。
Excelで在庫管理を自作するメリット
Excelの最大のメリットは、多くの企業ですでに導入されており、利用者が操作に慣れていることです。
商品コード、商品名、現在庫、保管場所などを一覧にすれば、すぐに在庫表を作れます。
さらに、
- SUMIFS
- XLOOKUP
- ピボットテーブル
- 入力規則
- 条件付き書式
などを利用すれば、かなり実用的な管理もできます。
VBAを使えば、
- CSV取込
- 在庫集計
- 棚卸表作成
- 発注候補抽出
- 帳票出力
などを自動化することもできます。
小規模な在庫管理では、Excelは有力な選択肢です。
Excelで在庫管理するなら3つの役割を分ける
Excelで自作する場合には、一枚のシートへすべてを入力するより、
- 商品マスタ
- 入出庫履歴
- 在庫一覧
を分けることをおすすめします。
商品マスタ
- 商品コード
- 商品名
- 分類
- 単位
- 仕入先
- 保管場所
- 発注点
などを登録します。
入出庫履歴
- 日付
- 処理区分
- 商品コード
- 数量
- 倉庫
- 担当者
- 備考
などを1件ずつ追加します。
在庫一覧
入出庫履歴を集計して現在庫を表示します。
この形にすると、現在庫だけを直接変更する運用を減らせます。
商品名ではなく商品コードを基準に管理する
Excel自作でよくある問題が表記ゆれです。
例えば、
- ボルト10mm
- ボルト 10mm
- 10mmボルト
が別の商品として入力されていると、正確な集計ができません。
商品コードを設定し、商品名は商品マスタから参照する形にすると、集計間違いを減らせます。
同じ考え方はAccessやWebシステムでも重要です。
Excel VBA・マクロは便利だが属人化に注意する
VBAを利用すると、
CSVを読み込む → 在庫を集計する → 不足商品を抽出する → 帳票を作る
といった作業をボタン一つで実行できます。
非常に便利です。
一方で機能を追加し続けると、Excelが実質的な業務システムになり、作成した担当者しか直せない状態になることがあります。
典型的なのが、
「今は動いているが、誰も仕組みを理解していない」
状態です。
VBAを利用するなら、
- 処理概要
- 更新履歴
- 設定値
- エラー対応
- バックアップ方法
などを残しておくことが重要です。
Excelで在庫管理を続ける限界のサイン
次のような状態が増えてきたら、Excelを改善し続けるか、次の仕組みへ移行するか検討します。
- Excelファイルが複数ある
- 最新版が分からない
- 複数人で同じファイルを編集している
- 数式やVBAを修正できる人が一人しかいない
- 毎月大量の手作業集計をしている
- データ量が増えて重い
- 在庫数が頻繁に合わない
- 複数倉庫のデータを集約している
- CSV加工が日常業務になっている
- バーコード対応したい
- POSやECと連携したい
Excelの限界は、「何行以上になったら」という一つの数字だけでは判断できません。
業務上の負担とリスクで判断します。
今のExcel・Accessを使い続けるべきか迷っている方へ
現在の管理方法をもとに、Excel継続・SaaS・テンプレート型・個別開発のどれが適しているか整理できます。
在庫管理システムの詳細を見る
在庫管理をExcelで続けていると、入出庫履歴、棚卸、在庫差異、複数人利用で限界が出やすくなります。Excel修正だけでなく、在庫管理システム化も相談できます。
Accessで在庫管理を自作するメリット
Accessは、Excelよりもデータベースとして情報を整理しやすいツールです。
例えば、
- 商品
- 倉庫
- 仕入先
- 入出庫
- 発注
などを別々のテーブルとして管理できます。
フォームを作れば、担当者はテーブルを直接編集せず、専用画面から入庫や出庫を登録できます。
クエリでは、
- 現在庫
- 発注点以下の商品
- 月別出庫数
- 滞留在庫
- 倉庫別在庫
などを抽出できます。
レポート機能では、
- 在庫一覧
- 棚卸表
- 発注書
などの帳票を作ることができます。
Excelよりデータ構造を整理したい、小規模から中規模程度の業務ではAccessが有効な選択肢になる場合があります。
Accessでは画面よりデータ構造が重要
Accessを作るとき、最初にフォームを作り始めるケースがあります。
しかし、本来はテーブル設計が先です。
例えば、
| テーブル | 主な内容 |
|---|---|
| 商品 | 商品コード、商品名、単位等 |
| 倉庫 | 倉庫名、所在地 |
| ロケーション | 倉庫内の棚・場所 |
| 入出庫 | 日付、商品、数量、区分 |
| 仕入先 | 仕入先情報 |
| 発注 | 発注日、仕入先等 |
| 発注明細 | 商品、数量等 |
のようにデータを分けます。
商品名や仕入先名を毎回直接入力するのではなく、IDで関連付けます。
Accessフォームで利用者の操作を簡単にする
Accessでは、
- 入庫登録
- 出庫登録
- 棚卸
- 商品検索
など、用途別にフォームを分ける方法があります。
利用者へすべての情報を表示する必要はありません。
入庫担当者なら、
- 商品
- 数量
- 入庫場所
- 日付
といった必要項目だけを見せる方が分かりやすくなります。
システムは「高機能」であることより、
現場が迷わず使えること
が重要です。
Accessクエリで在庫を集計する
Accessのクエリを使えば、
- 商品別現在庫
- 倉庫別現在庫
- 発注点以下の商品
- 月別出庫実績
- 滞留在庫
などを集計できます。
ただし、テーブル結合の設計を誤ると、同じデータが複数回集計されて数量が増えてしまうことがあります。
クエリの結果は実際のデータと照合して確認する必要があります。
Accessで棚卸表や在庫一覧を作成する
レポート機能を使えば、
- 在庫一覧
- 棚卸表
- 発注書
- 月次レポート
などを出力できます。
また、Accessですべて完結させる必要もありません。
データ管理はAccessで行い、分析や提出資料はExcelに出力する方法もあります。
Access在庫管理の限界
Accessは便利ですが、規模が大きくなると課題も発生します。
例えば、
- 複数拠点で利用したい
- 同時利用者が増えた
- スマートフォンで利用したい
- ECと常時連携したい
- 多数の外部システムと接続したい
- VBAが複雑化している
といった場合です。
また、長年利用しているAccessでは、
- 仕様書がない
- 開発担当者が退職した
- VBAを理解する人がいない
- Office更新後に不具合が出る
- 古いMDBを利用している
といった問題も発生します。
この段階では、Accessを修正して延命するのか、Web化するのかを判断する必要があります。
AccessからWeb化するときに全部を再現しない
古いAccessシステムに50画面あるからといって、新システムでも50画面すべて作る必要はありません。
例えば、
- 毎日使っている画面：15
- たまに使う画面：5
- 現在は使っていない画面：30
というケースもあります。
その場合には、
- 残す
- 統合する
- なくす
- Web化する
を整理します。
Accessを忠実に再現することが目的ではありません。
現在の業務をより使いやすくすることが目的です。
Webシステムで在庫管理するメリット
Webシステムにすると、ブラウザから在庫管理を利用できます。
例えば、
- 大阪倉庫
- 東京倉庫
- 本社
- 営業所
などから同じ在庫情報を利用できます。
利用者ごとにIDを発行し、
- 一般担当者
- 倉庫責任者
- 管理者
などの権限を設定することもできます。
また、
- スマートフォン
- タブレット
- バーコード端末
から操作することも可能です。
外部システムとの連携も設計しやすくなります。
Webシステムを自作する場合は保守まで考える
Web開発では、画面を作れば終わりではありません。
少なくとも、
- ログイン
- 権限
- データベース
- 通信
- バックアップ
- 操作ログ
- エラー処理
- サーバー
- セキュリティ更新
- ソースコード管理
- テスト
などを考える必要があります。
重要な在庫データを扱うシステムなら、作成後の運用責任も重要です。
Pythonは在庫システムそのものではなく周辺自動化にも使える
Pythonは、
- CSV取込
- データ変換
- 在庫集計
- 発注候補抽出
- 定期レポート
- ファイル連携
などの自動化に利用できます。
例えば、
販売管理からCSVを取得 → 商品コードを照合 → 出庫データを作成 → 在庫データを更新 → エラー一覧を出力
といった処理も考えられます。
Pythonだけでシステム全体を作る必要はありません。
Excel、Access、Webシステムの補助ツールとして使う方法もあります。
SaaSの在庫管理システムを使った方がよい場合
標準的な在庫管理業務なら、自作よりSaaSの方が適しているケースがあります。
例えば、
- 商品マスタ
- 入出庫
- 棚卸
- バーコード
- 複数拠点
- 権限管理
などが既製サービスの標準機能で十分に実現できる場合です。
この場合には、無理に自社開発する必要はありません。
サーバー構築や基本的なアップデートをサービス提供会社へ任せられるメリットもあります。
SaaSの標準機能に業務を合わせられるかが重要
SaaSは導入しやすい一方、自社独自の処理へ完全には対応できない場合があります。
例えば、
- 独自の商品項目
- 特殊な在庫計算
- 独自帳票
- 特殊なCSV
- 複雑な入出庫処理
- 既存基幹システムとの独自連携
などです。
SaaSを選ぶ際には、
「この機能があるか」
だけでなく、
自社の業務を標準機能へ合わせても問題ないか
を確認します。
自作とSaaSの間に「テンプレート型カスタマイズ」という方法がある
在庫管理では、
Excel・Accessでは限界がある。
SaaSでは自社業務に合わない。
しかしフルスクラッチで全部作るほどではない。
という企業があります。
この場合には、テンプレート型カスタマイズが選択肢になります。
一般的な在庫管理で共通する、
- 商品マスタ
- 倉庫
- ロケーション
- 入庫
- 出庫
- 在庫一覧
- 在庫移動
- 入出庫履歴
- 棚卸し
- CSV
- 帳票
- 権限
などを共通機能として用意します。
会社ごとに異なる部分だけを追加・変更します。
Mactism Quick Pack 在庫管理とは
マクティズムでは、この考え方による「Mactism Quick Pack 在庫管理」を提供しています。
対象となるのは、例えば次のような企業です。
- Excelの在庫管理が複雑化した
- Accessが古くなり保守できない
- SaaSを比較したが合わなかった
- 自社固有の商品項目がある
- 現在の帳票を一部残したい
- 独自CSVを利用している
- 複数倉庫へ対応したい
- 最初は在庫だけシステム化したい
- 将来、発注や販売まで拡張したい
Quick Packは、
SaaSでは業務に合わない
しかし、
フルスクラッチほど大きく始めたくない
企業向けの位置づけです。
既製SaaSでは合わないが、一から全部作るほどではない方へ
Mactism Quick Pack 在庫管理では、基本機能をテンプレート化し、必要な部分だけを自社向けにカスタマイズできます。
在庫管理システムの詳細を見る
在庫管理をExcelで続けていると、入出庫履歴、棚卸、在庫差異、複数人利用で限界が出やすくなります。Excel修正だけでなく、在庫管理システム化も相談できます。
Quick Packの基本機能
テンプレートとして想定している主な機能は次のとおりです。
| 機能 | 内容 |
|---|---|
| 商品・品目マスタ | 商品情報を管理 |
| 倉庫・保管場所 | 倉庫・ロケーションを管理 |
| 入庫 | 入庫数量を登録 |
| 出庫 | 出庫数量を登録 |
| 在庫移動 | 倉庫・棚間移動 |
| 在庫一覧 | 現在庫を確認 |
| 入出庫履歴 | 数量変動を確認 |
| 棚卸 | 棚卸実績・差異を管理 |
| CSV取込 | 既存データを取り込み |
| CSV出力 | データを出力 |
| 帳票 | 在庫一覧等を出力 |
| 権限 | 利用者権限を管理 |
バーコード、QR、RFID、ハンディ端末、外部システム連携などは、必要性を確認して追加します。
最初から全部作らない
在庫管理システムの相談では、
- 「バーコードも欲しい」
- 「ロットも必要」
- 「発注もしたい」
- 「AIも使いたい」
と機能が増えやすくなります。
しかし、最初の問題が、
「在庫の最新数量が分からない」
ことなのであれば、まず、
商品 ＋ 入庫 ＋ 出庫 ＋ 在庫一覧 ＋ 棚卸し
で改善できる可能性があります。
その後、
ロケーション → バーコード → 発注 → POS・EC → 基幹システム
と拡張できます。
自作を続けるべきか判断するチェックポイント
| 項目 | 自作を続けやすい | システム化を検討 |
|---|---|---|
| 利用人数 | 1〜少人数 | 多人数 |
| 拠点 | 1拠点 | 複数拠点 |
| 入出庫件数 | 少ない | 多い |
| 同時利用 | 少ない | 多い |
| 権限管理 | 簡易でよい | 詳細な制御が必要 |
| 履歴 | 簡易 | 厳密 |
| 連携 | CSV程度 | API・基幹連携 |
| バーコード | 不要 | 必要 |
| 保守担当 | 社内にいる | 不在 |
| 将来拡張 | 小さい | 大きい |
一つ当てはまっただけでWeb化する必要はありません。
複数の問題が重なり、業務リスクや作業時間が大きくなっているかを確認します。
Excel・Accessを捨てずに在庫管理をシステム化する
Webシステムへ移行する場合でも、ExcelやAccessをすべて廃止する必要はありません。
例えば、
- 在庫データの正本はWebシステム
- 分析・資料作成はExcel
という役割分担もできます。
現在使っているExcel帳票を、新システムから出力できるようにする方法もあります。
Accessについても、すべてを一度に置き換えるのではなく、重要な在庫管理部分から段階的にWeb化する方法があります。
自作から移行するときはデータ整理が重要
システム移行で大きな問題になりやすいのがデータです。
現在のExcelやAccessに、
- 商品コードの重複
- 商品名の表記ゆれ
- 単位の不統一
- 古い商品
- 不要データ
- 現在庫だけで履歴がない
といった問題があると、新システムへそのまま移しても問題が残ります。
移行前にデータを整理します。
商品コード・単位を統一する
例えば同じ商品が、
- A001
- 1
- A-001
の3種類で登録されている場合、どれを正式なコードにするか決めます。
また、
- 1ケース
- 12個
が混在している場合には、換算ルールを決めます。
自作か外注かに関係なく、マスタ整理は重要です。
在庫管理では例外処理が重要
通常の入庫と出庫だけならシステムは比較的簡単です。
しかし現場では、
- 返品
- 取消
- 廃棄
- 破損
- 在庫移動
- 入力訂正
- 棚卸差異
が発生します。
この処理を作っていないと、現場では在庫数を直接変更するようになります。
結果として、
「なぜ在庫が変わったのか分からない」
状態になります。
誰がいつ変更したかを残す
複数人で利用する場合には、
- 担当者
- 日時
- 変更前
- 変更後
- 理由
を残すことが重要です。
簡易なExcelでは不要な場合もあります。
ただし、在庫金額が大きい企業や多数の担当者が操作する場合には、操作履歴も含めて検討します。
バックアップは「取った」ではなく「復元できる」が重要
ExcelやAccessで定期的にバックアップしていても、復元したことがなければ十分とはいえません。
バックアップファイルが、
- 壊れている
- 古い
- 復元方法を知る人がいない
というケースがあります。
一定期間ごとに復元方法まで確認しておくことが重要です。
自作システムで起こりやすい5つの失敗
1．Excelが複数に増える
最初は一つだった在庫ファイルが、
- 営業用
- 倉庫用
- 事務用
- 最新版
- 最新版2
と増えていきます。
この状態では、どのデータが正しいか分かりません。
2．現在庫を直接修正する
差異が出るたびに、
100 → 98
と修正すると、なぜ2個減ったか分からなくなります。
棚卸調整として履歴を残すことが重要です。
3．VBAが巨大化する
最初は集計だけだったVBAへ、
- 発注
- 帳票
- CSV
- メール
- 棚卸し
などを追加し続けます。
作成者以外に直せなくなると保守リスクになります。
4．AccessをExcelと同じ構造で作る
大きな一覧表をAccessへ移しただけでは、データベースのメリットを活かせません。
商品、仕入先、入出庫などを適切に分ける必要があります。
5．Web開発中に機能が増え続ける
当初は在庫一覧だけだったのに、
- バーコード
- ロット
- 期限
- EC連携
- 発注
- 承認
と追加されると、設計変更が必要になります。
最初に、
- 今回
- 次期
- 将来
へ分けておくことが重要です。
自作する場合の具体的な進め方
STEP1 現場の作業を見る
実際にどのように入荷し、出荷し、棚卸ししているか確認します。
STEP2 現在のファイルを集める
Excel、Access、CSV、紙帳票などを集めます。
STEP3 必要なデータを整理する
商品コード、数量、単位、倉庫、担当者などを整理します。
STEP4 必須機能を決める
最初から全機能を作りません。
STEP5 Excel・Access・SaaS・Webを比較する
現在と将来の利用規模で判断します。
STEP6 小さく試す
1拠点や代表商品でテストします。
STEP7 例外処理を確認する
返品、修正、廃棄、移動などをテストします。
STEP8 本番移行
現在庫を確定し、新しい運用へ切り替えます。
STEP9 運用後に改善する
実際に使って分かった問題を改善します。
自作と外注を費用だけで比較しない
自作では外部への支払いが少ないため、安く見えます。
しかし社員が100時間作業したなら、その人件費も実質的な開発費です。
さらに、
- 設計
- テスト
- マニュアル
- 教育
- 障害対応
- 改修
にかかる時間もあります。
そのため、
外部へ払う金額だけ
ではなく、
自社で使う時間
まで含めて比較します。
外注を検討した方がよいサイン
次のような状態がある場合には、外部へ相談する価値があります。
- Excel・Accessを作った担当者がいない
- 仕様書がない
- システム停止が業務へ大きく影響する
- 在庫金額が大きい
- 複数拠点へ展開する
- POSやECと連携する
- 基幹システムと連携する
- セキュリティ要件が高い
- 社内で継続保守できない
「作れないから外注する」のではありません。
継続運用と事業リスクを考えて外注する
という判断です。
外注する場合でも全面刷新とは限らない
現在のExcelやAccessが複雑になっている企業では、
「開発会社へ相談したら全部作り直されるのではないか」
と考えることがあります。
しかし、本来は、
- 修正で済むもの
- 残した方がよいもの
- Web化すべきもの
- 廃止できるもの
を分けるべきです。
在庫管理全体を見直した結果、
「今はExcel修正で十分」
という結論になる可能性もあります。
Mactism Quick Pack 在庫管理の費用目安
マクティズムでは、Excel・Access・紙の管理から段階的に移行できるテンプレート型在庫管理システムを提供しています。
| 内容 | 費用目安 | 主なケース |
|---|---|---|
| テンプレート導入・軽微調整 | 150万〜300万円 | Excel等から基本的な在庫管理へ移行 |
| 業務カスタマイズ | 300万〜600万円 | 入出庫・棚卸・帳票・ロケーション等を調整 |
| 拡張・システム連携 | 600万〜1,200万円 | 発注・販売・基幹連携等 |
| 保守・改善 | 月3万〜10万円 | 導入後の改善・軽微改修 |
実際の費用は、データ移行、画面、帳票、バーコード、外部システム連携などによって変わります。
月額数千円程度のサービスで十分な場合には、一般的なSaaSを利用する方が適しています。
どの方法を選ぶべきか判断する簡易フロー
Excelを続ける
少人数・1拠点・簡単な管理・連携不要 → Excelを整理して継続
Accessを利用する
商品・履歴を分けたい・少人数利用・社内中心・帳票が多い → Accessでデータベース化
SaaSを利用する
標準的な在庫管理・短期間で始めたい・業務を標準機能へ合わせられる → 既製SaaSを比較
Quick Packを検討する
Excel・Accessでは限界・SaaSでは一部合わない・独自帳票・項目・CSVがある・必要部分だけ自社仕様にしたい → テンプレート型カスタマイズ
フルスクラッチを検討する
非常に独自な業務・多数のシステム連携・企業全体の再構築 → フルスクラッチ・基幹再構築
在庫管理システムを外注するときに準備する情報
要件定義書が完成していなくても相談できます。
最低限、
- 現在使っているExcel・Access
- 現在困っていること
- 利用人数
- 拠点数
- 商品数
- 連携したいシステム
- 希望する時期
が分かれば、現状整理を始められます。
現在のExcelやAccessそのものが、業務を説明する重要な資料になります。
最初から「在庫管理システム一式」で見積もりを取らない
対象範囲が曖昧な状態で複数社へ見積もりを依頼すると、
- A社：SaaS導入
- B社：テンプレート型
- C社：フルスクラッチ
となり、金額を正しく比較できません。
「在庫管理システム」の中にどこまで含むかを整理します。
まず現在の在庫管理方法を整理する方法もある
「システムを作るべきかどうか分からない」
という状態なら、いきなり開発する必要はありません。
現在のExcel、Access、帳票、業務フローを確認し、
- 修正
- 延命
- 部分Web化
- Quick Pack
- 全面再構築
のどれが適しているか整理します。
自作を続ける場合に最低限残す資料
自作の場合でも、
- システム概要
- ファイル一覧
- 商品マスタ項目
- 入出庫ルール
- バックアップ方法
- エラー時の対応
- VBA等の処理概要
- 変更履歴
- 担当者
程度は残しておくことをおすすめします。
詳細な設計書でなくても構いません。
次の担当者が理解できる状態が重要です。
自作在庫管理の安全運用チェックリスト
| 確認項目 | 状態 |
|---|---|
| 正本 | 正式データがどれか決まっている |
| 商品コード | 重複しないコードがある |
| 単位 | 個・箱等のルールがある |
| 入出庫 | 登録タイミングが決まっている |
| 返品・廃棄 | 通常処理と区別している |
| 棚卸 | 差異理由を残している |
| バックアップ | 定期取得している |
| 復元 | 復元手順を確認している |
| 権限 | 誰でも変更できる状態ではない |
| 保守 | 担当者または外部支援がある |
| ドキュメント | 基本仕様が残っている |
| データ出力 | CSV等で移行可能 |
多くの項目が未整備で、重要な在庫を扱っているのであれば、現在の運用を一度見直す価値があります。
マクティズムが考える「自作」と「在庫管理システム」
マクティズムでは、ExcelやAccessによる自作を否定していません。
小規模な業務ならExcelが最も適しているケースがあります。
Accessを修正して使い続ける方が合理的なケースもあります。
重要なのは、
Webシステムの方が新しいからWeb化する
ことではありません。
現在の業務に合っているかどうかです。
そのため、
- Excelで十分ならExcel
- Access修正で済むならAccess
- SaaSで十分ならSaaS
- SaaSで不足するならQuick Pack
- 非常に独自ならフルスクラッチ
という順番で考えることをおすすめします。
「全部一から作らない」という考え方
フルスクラッチなら自由に機能を設計できます。
しかし、在庫管理には多くの企業に共通する、
- 商品
- 倉庫
- 入庫
- 出庫
- 在庫一覧
- 棚卸し
という機能があります。
これらを毎回ゼロから作れば、その分だけ費用と期間が必要です。
Mactism Quick Pack 在庫管理では共通部分をテンプレート化し、自社固有の部分へ開発工数を使う考え方を採用しています。
まとめ｜在庫管理システムは「自作できるか」ではなく「どの方法が自社に合うか」で選ぶ
在庫管理システムはExcel、Access、Python、Webなどで自作できます。
小規模で、
- 利用者が少ない
- 商品数が少ない
- 入出庫が単純
- 外部連携が不要
- 社内で保守できる
という場合には、自作は有効な方法です。
しかし、事業が拡大し、
- 利用者が増える
- 拠点が増える
- データ量が増える
- 外部システムと連携する
- 権限管理が必要になる
- 担当者が退職する
といった変化が起きれば、自作を維持する負担は大きくなります。
重要なのは、
現在動いているか
だけではありません。
今後も安全に運用し、修正し、引き継げるか
まで考えることです。
また、自作の限界を感じたからといって、いきなりフルスクラッチで全面再構築する必要もありません。
標準的な在庫管理ならSaaSがあります。
SaaSでは自社業務に合わないものの、すべてを一から作る必要がない場合には、テンプレート型カスタマイズがあります。
在庫だけではなく販売・生産・購買まで大きく見直す場合には、基幹システム再構築を検討します。
つまり選択肢は、
- Excelを残す
- Accessを修正する
- SaaSへ移行する
- テンプレート型在庫管理へ移行する
- フルスクラッチで再構築する
の5つです。
マクティズムでは、Excel・Access・Webシステムのいずれかへ無理に誘導するのではなく、現在の在庫管理方法を確認し、
- 残すもの
- 直すもの
- なくすもの
- システム化するもの
を整理することから検討できます。
- 「Excelをまだ使い続けるべきか分からない」
- 「Accessを修正するべきかWeb化するべきか迷っている」
- 「SaaSを比較したが、自社に合うものが見つからない」
- 「在庫管理を改善したいが、必要な機能が分からない」
という段階でも構いません。
まだシステム方式を決める必要はありません。
現在のExcel・Access・紙の管理方法をもとに、SaaSで十分なのか、Mactism Quick Pack 在庫管理が適しているのか、より大規模な開発が必要なのかを整理できます。
在庫管理システムの詳細を見る
在庫管理をExcelで続けていると、入出庫履歴、棚卸、在庫差異、複数人利用で限界が出やすくなります。Excel修正だけでなく、在庫管理システム化も相談できます。
在庫管理そのものの改善を目的に考え、その結果としてExcel・Access・SaaS・Quick Pack・フルスクラッチのどれを選ぶか判断することが、無駄な開発費を防ぎ、長く使える仕組みを作る第一歩です。
