Excelで管理していた案件・在庫・発注業務をkintoneで再構築業務全体をつなぐDX事例
Excelやマクロで複雑化していた案件・在庫・発注業務を、kintoneを中心に再構築した導入事例。複数アプリの自動連携、Excel・CSVのデータ活用、需給計画ではExcelを残すなど、業務に合わせてkintone・Excel・外部連携を組み合わせたシステム構築をご紹介します。
案件管理、在庫管理、入荷予定、需給計画、発注。
それぞれをExcelで管理しているうちに、ファイルやマクロが増え、
「同じ情報を何度も入力・転記している」
「確認したい情報が複数のExcelに分かれている」
「担当者しか分からない作業が増えている」
「仕組みが複雑になり、簡単には変更できない」
といった状態になっていないでしょうか。
今回は、こうした複数のExcelにまたがっていた案件・在庫・発注業務を整理し、kintoneを中心に業務全体をつなぎ直した事例をご紹介します。
単にExcelをkintoneへ置き換えたわけではありません。
登録した案件を後工程の管理データへ自動で展開し、在庫・入荷予定などの情報とつなげ、需給計画や発注判断まで利用できる仕組みに再構築しました。
一方で、Excelの方が使いやすい業務はあえて残しています。
kintone、Excel、自動連携、プラグイン、JavaScriptなどを組み合わせ、業務に合わせてシステム全体を設計した事例です。
※本記事では実際の導入事例をもとに、企業名・商品名・拠点名・業務固有の名称などを変更・省略して紹介しています。
Excelで作り込まれた業務管理が限界に
導入前は、案件・在庫・入荷・発注などの業務を複数のExcelで管理していました。
Excelは自由度が高く、業務に合わせて機能を追加できます。
しかし、
案件管理表に項目を追加する。
必要な集計表を増やす。
別のExcelへデータを連携する。
マクロで処理を自動化する。
と改善を重ねるうちに、Excelそのものが業務システムのようになっていました。
その結果、
- ファイルが重く、動作が不安定になる
- マクロのエラーが業務に影響する
- 同じ情報を複数のExcelで扱う必要がある
- Excel同士のつながりや処理が複雑になる
- 担当者しか分からない処理が増える
- 業務変更に合わせた修正が難しくなる
- 過去データを蓄積・活用しにくい
といった問題が発生していました。
一つひとつExcelを修正し続けるのではなく、業務全体でどの情報を管理し、どのようにつなげるべきかを整理し直す必要がある状態になっていました。
そこで、既存のExcelをそのまま置き換えるのではなく、業務とデータの流れから見直すことにしました。
Excelをそのままkintoneに置き換えるだけでは解決しない
最初に行ったのは、既存Excelをそのままkintoneアプリに再現することではありません。
例えば営業担当者にとっては、
「顧客Aの案件で、複数の商品を受注する」
という1件の案件として入力できた方が分かりやすいでしょう。
一方、その後の業務では、
- 出庫する倉庫ごとに分けて確認したい
- 商品区分ごとに処理したい
- 一部の商品だけ先に出荷したい
- 在庫では商品単位で数量を把握したい
といった違いがあります。
つまり、営業が入力しやすいデータの形と、出荷・在庫・集計で使いやすいデータの形は同じとは限りません。
これまでは、こうした違いを複数のExcelやマクロ、転記作業で吸収していました。
今回の再構築では、その処理自体をシステムの中へ組み込んでいます。
案件を起点に、後工程のデータを自動で作る
例えば営業担当者が、次のような案件を登録したとします。
案件A
- 商品A：10個
- 商品B：20個
- 商品C：5個
営業側では一つの案件として管理します。
一方、後工程では出庫する倉庫や商品区分などに応じて、別々に管理したい場合があります。
そこで案件を登録すると、明細を必要な単位に分け、
案件管理アプリ
↓
出荷・案件明細アプリ
↓
商品単位の在庫管理アプリ
へ自動的にデータを展開する仕組みにしました。
案件の数量や出荷予定日を変更した場合も、関連するデータへ反映します。
営業担当者が後工程用のアプリに同じ情報を再入力する必要はありません。
人や複雑なマクロで行っていたデータの受け渡しを、案件登録を起点とした連携へ置き換えています。
案件・在庫・入荷情報を、一続きのデータとして扱う
案件管理と在庫管理をそれぞれkintone化するだけでは、業務全体がつながったことにはなりません。
例えば現在庫が100個あっても、近いうちに80個を出荷する予定なら、実際に使える在庫は限られます。
さらに、その後に50個の入荷予定があれば、発注判断も変わります。
そこで今回の仕組みでは、
- 現在の在庫
- 登録済みの案件
- 出荷予定
- 入荷予定
- 生産予定
- 商談の状況
など、将来の在庫に影響する情報をつなげています。
案件を変更すれば関連する在庫情報にも反映され、入荷予定や棚卸データを取り込めば、その情報も在庫管理へ加わります。
それぞれ別々に存在していた情報を、在庫や発注を判断するための一続きのデータとして利用できるようにしました。
kintoneだけに寄せず、Excelが使いやすい業務は残す
今回のシステムでも、すべてをkintoneへ移したわけではありません。
例えば、商品ごとに行を並べ、月を横方向に展開しながら、在庫の推移や入荷・出荷予定を数か月先まで確認して、発注数量を調整するような業務です。
こうした、複数月の数字を横並びで見ながら判断する作業は、Excelの方が使いやすい場合があります。
そこで、役割を次のように分けました。
- 案件入力・データ管理・共有 → kintone
- 大量の数字を確認する需給計画 → Excel
Excel側ではkintoneのデータを取得して将来の在庫推移を確認し、担当者が調整した数量は再びkintoneへ戻して、その後の発注処理や帳票に利用します。
以前はExcelの中にデータと業務ロジックの多くが閉じ込められていました。
再構築後は、データの中心をkintoneに置き、Excelは数字を確認・判断するための画面として使う構成になっています。
案件情報を、発注判断までつなげる
在庫管理では、「今何個あるか」だけ分かっても十分ではありません。
今後どれくらい出荷するのか。
どれくらい入荷するのか。
商品を調達するまでどの程度かかるのか。
どの程度の在庫を持っておく必要があるのか。
こうした情報も発注判断には必要です。
今回の仕組みでは、kintoneに蓄積した案件・在庫・入荷などのデータを需給計画へ利用し、一定期間先までの在庫を確認できるようにしました。
さらに、発注ロットや必要在庫、案件の見込みなども加味しながら担当者が発注予定数を判断し、その結果を発注処理や帳票へつなげます。
案件管理のために入力した情報を、その後の在庫管理や発注判断まで利用できる状態を作っています。
自動連携は「つなぐだけ」では安定しない
複数のアプリを自動連携する場合、単純にデータをコピーするだけでは安定しないことがあります。
例えば、案件を保存した直後に裏側の処理が関連データを更新し、その最中に利用者がもう一度編集すると、更新が競合する可能性があります。
また、自動更新が別の処理を呼び出し、更新が繰り返されることも防ぐ必要があります。
そこで今回のシステムでは、更新元の判別やデータの状態確認、変更・削除時の関連データとの整合性なども含めて制御しています。
画面上では単純に見える処理でも、実際に日常業務で安定して使えるようにするための設計まで行っています。
改善したのは「Excel」ではなく、業務を流れるデータ
今回の改善で重要なのは、Excelをkintoneに変更したこと自体ではありません。
以前は、複数のExcelに情報が分かれ、人や複雑なマクロが、それぞれの情報の間をつないでいました。
再構築後は、
案件を登録する
↓
出荷管理用のデータを自動生成する
↓
在庫・入荷情報とつなげる
↓
将来の在庫を確認する
↓
発注予定を決める
というように、業務に沿ってデータが流れる構成になっています。
kintoneの標準機能だけにこだわらない
今回の構築では、
- kintone標準機能
- JavaScriptカスタマイズ
- kintoneプラグイン
- 外部の自動連携サービス（Make）
- Excel
- Excelマクロ
などを組み合わせています。
重要なのは、「すべてkintoneで作ること」ではありません。
業務を整理したうえで、
- どこをkintoneで管理するのか
- どこを自動連携するのか
- どこはExcelを残した方が使いやすいのか
を判断しています。
既存の仕組みを活かしながら、必要な部分だけを作り直すこともできます。
同じシステムでなくても、似た困りごとはありませんか？
今回とまったく同じ業務を行っている企業は多くありません。
しかし、
- Excelファイルやマクロが増え続けている
- 担当者しか分からない業務がある
- 同じ情報を複数のシステムへ入力している
- 部門ごとに別々のデータを管理している
- 基幹システムからExcelを出して加工している
- kintoneを導入したものの、Excelへの転記が残っている
- システムとシステムの間を人がつないでいる
- 基幹システムは残したまま周辺業務を改善したい
といった状況は、さまざまな企業で起こります。
こうしたケースでは、一つのツールを導入するだけでは解決できないことがあります。
現在の業務とデータの流れを整理し、残す仕組み、kintoneへ移す仕組み、自動化する仕組みを分けて考えることが重要です。
kintoneの構築から、基幹システム周辺の業務改善まで対応します
多助太郎では、kintoneを便利にするプラグインを提供しています。
一方で、次のようなケースについては、個別のkintone開発や基幹DX支援として対応しています。
- 複数のkintoneアプリを連携したい
- Excelとkintoneを組み合わせたい
- 既存システムから出力したデータを活用したい
- 複数の業務にまたがった仕組みを整理したい
小さな入力改善であれば、多助太郎のプラグインで解決できる場合があります。
複数アプリの連携や独自処理が必要であれば、kintoneの受託開発として対応できます。
さらに、基幹システム・kintone・Excelを含めて業務全体を見直したい場合には、多助太郎の運営会社ARTICULの「基幹DXサポート」として、業務整理からシステム構成の検討、開発までご相談いただけます。
「今のExcelが限界だが、何に置き換えればいいか分からない」
「kintoneを使っているが、結局Excelへの転記が残っている」
「基幹システムには手を入れにくいが、その周辺業務を改善したい」
といった段階でも対応可能です。
現在の仕組みを確認し、残すものと改善するものを整理したうえで、業務に合った構成をご提案します。
よくある質問（8件）
Excelで管理している案件・在庫・発注業務をkintoneへ移行できますか？
はい。ARTICULでは、既存のExcelやマクロの内容を確認したうえで、kintoneへの移行だけでなく、業務やデータの流れを整理したシステム再構築にも対応しています。すべてをkintoneへ置き換えるのではなく、Excelを残した方が使いやすい業務も含めて構成をご提案できます。
複数のkintoneアプリを自動連携するシステムも開発できますか？
できます。案件登録を起点に別アプリへデータを展開したり、在庫・入荷・発注など複数アプリの情報を連携したりする個別開発に対応しています。JavaScript、kintone API、プラグイン、外部連携サービスなどを業務に合わせて組み合わせます。
kintoneとExcelを組み合わせたシステムも構築できますか？
できます。データ管理や共有はkintone、複数月の数字を確認する需給計画などはExcelというように、それぞれの得意分野を活かした構成が可能です。kintoneからExcelへのデータ連携や、Excelで調整した情報をkintoneへ戻す仕組みもご相談いただけます。
基幹システムは残したまま、kintoneやExcelで周辺業務を改善できますか？
はい。ARTICULの基幹DXサポートでは、既存の基幹システムをそのまま利用しながら、案件管理・在庫管理・発注・Excel加工・データ転記などの周辺業務をkintoneやExcel、自動連携によって改善するご相談に対応しています。
kintoneの標準機能やプラグインだけでは実現できない業務も相談できますか？
はい。小さな機能追加であれば多助太郎のkintoneプラグイン、複数アプリの連携や独自処理が必要な場合はkintone受託開発、基幹システム・kintone・Excelを含めた業務全体の見直しは基幹DXサポートとして対応できます。
多助太郎のプラグインとkintone受託開発、基幹DXサポートはどう使い分ければよいですか？
一覧・入力・データ連携など、一般的なkintoneの機能追加であれば多助太郎のプラグインが向いています。自社独自の処理や複数アプリ連携が必要ならkintone受託開発、基幹システムやExcelまで含めて業務全体を整理したい場合はARTICULの基幹DXサポートが向いています。
受注・見積・在庫・発注など、複数の業務をまとめて改善することもできますか？
できます。一つの画面だけを改善するのではなく、受注・案件・在庫・入荷・発注など、前後の業務でデータをどのようにつなぐべきかを整理し、kintone・Excel・外部連携などを組み合わせた仕組みをご提案できます。
何をkintone化すればよいか決まっていない段階でも相談できますか？
はい。「Excelやマクロが複雑になっている」「kintoneを導入したがExcel転記が残っている」「基幹システムは変更できないが周辺業務を改善したい」といった段階からご相談いただけます。ARTICULが現在の業務とデータの流れを確認し、プラグイン・受託開発・基幹DXの中から適した方法をご提案します。