ブログ
基幹業務のリプレイスでは、単に旧システムを新しい仕組みに置き換えれば終わるわけではありません。
特に、複数部署にまたがる販売管理業務では、部署ごとに異なる運用や個別最適化されたフローが存在し、要件整理そのものが難航しやすくなります。
さらに、Excelやマクロ、既存システム、手作業が混在している場合は、どこを残し、どこを新しいシステムに置き換えるかを慎重に見極める必要があります。
要件が曖昧なまま進めてしまうと、リプレイス後に業務が回らなくなる、現場負荷が増える、スケジュールが崩れるといった問題につながりかねません。
今回紹介するのは、複数部署にまたがる基幹業務を対象に、楽楽販売を用いてリプレイスを行った導入支援プロジェクトです。
blueは、要件定義フェーズから開発、保守まで一貫して関わり、曖昧な要件や複雑な部署間調整がある中でも、現場に寄り添いながら稼働まで伴走しました。
この記事では、複数システムやExcel管理が混在する基幹業務をどう整理し、どのように楽楽販売へ落とし込んでいったのか、その進め方とポイントを紹介します。
👉 この記事で学べるポイント:
- 複数部署にまたがる基幹業務リプレイスが難しくなりやすい理由
- 楽楽販売導入において、設定だけでなく業務整理が重要になる背景
- blueが要件整理から稼働後保守まで伴走した進め方
- 大規模な導入支援案件で、現場に寄り添いながら前進させる考え方
INDEX
プロジェクト概要:複数部署にまたがる基幹業務を、楽楽販売へリプレイスしたかった
今回のプロジェクトは、見積から受注、発注、出荷、納品検収、請求、売上・支払データの作成、契約管理、メール送付までを含む販売管理基幹業務を、楽楽販売でリプレイスしていく導入支援案件でした。
対象となったのは、本社部門と地域拠点を含む複数部署にまたがる販売管理業務です。それぞれの部署が関わるフローや利用している管理方法が異なっており、案件管理や見積、受注、請求、支払などの各工程で、Excel、マクロ、他システム、手作業が混在していました。
この案件の目的は、旧基幹システムの老朽化に対応しつつ、販売管理業務を新しい仕組みに移行し、関連する業務の効率化を図ることでした。
単にシステムを置き換えるだけではなく、複数システムにまたがっていた業務やデータの流れを整理し、楽楽販売を中心に運用可能な形へ再構成する必要がありました。
つまりこの案件は、楽楽販売の構築案件であると同時に、複数部署・複数システムにまたがる基幹業務そのものを見直す、大規模な導入支援プロジェクトだったと言えます。
課題1:複数部署が関わる中で、要件整理そのものが難しかった
この案件で最も大きな難しさのひとつは、関係部署が多く、業務全体を横断して整理すること自体が簡単ではなかった点です。
部署ごとに担当している業務が異なれば、見えている範囲も異なります。そのため、自部署の業務は理解していても、前後工程や他部署とのつながりまでは把握しきれていないことが少なくありません。
今回も、クライアント側では要件整理が進行途中の状態で、要件定義や開発は止まっていました。一度決まった内容でも、他部署が関わることで再調整が必要になる場面があり、部署間で思惑が異なるケースでは意思決定にも時間がかかっていました。
また、親会社からの業務継承や既存基幹システムの老朽化といった背景もあり、単純な業務改善ではなく、「今後も回り続ける業務の全体像」をどう設計するかが問われていた点も、この案件を難しくしていました。
つまり課題は、システムの機能不足ではなく、複数部署にまたがる業務をどう整理し、誰が何を判断し、どのフローで回すのかを全体で設計することにありました。
課題2:Excel・マクロ・他システムが混在し、属人化した業務が残っていた
もうひとつの大きな課題は、既存業務の管理方法が統一されていなかったことです。
クライアントでは、Excel、マクロ、他システム、手作業を組み合わせて販売管理業務を運用しており、現行業務をシステムだけでは管理しきれていない部分が残っていました。
そのため、業務引き継ぎが煩雑になりやすく、担当者に依存した運用も発生していました。
こうした状態では、たとえ新しいシステムを導入しても、単純に旧運用を移植するだけでは同じ問題を繰り返す可能性があります。
また、既存の運用に合わせてすべてを残そうとすると、システムの設計が複雑になり、結果として使いにくい仕組みになることもあります。
この案件では、案件管理や見積、受注、請求、売上・支払データ作成など、販売管理の主要な業務に加え、SFA連携やCSV連携、帳票出力なども対象になっていました。
つまり、単に楽楽販売へデータを移すのではなく、複数の管理方法やシステム連携をどう整理し、どこまで一元化するかを考える必要がありました。
blueの対応1:現状把握と業務理解から入り、前提を整理し直した
blueが最初に着手したのは、現状把握と業務理解でした。
過去ベンダーとのやり取りや既存ドキュメントを確認し、それらが本当に正しい内容なのかを再確認しながら、現在の業務実態を把握していきました。
前ベンダーとある程度固められていた内容も、そのまま踏襲するのではなく、楽楽販売の仕様や実際の運用に照らして整理し直す必要がありました。
この案件では、クライアント側でも要件や整理が進んでいた部分はありましたが、それだけでは実際の設計や開発を前に進めるには不十分でした。
そこでblueは、業務フロー、システムフロー、帳票、既存の管理方法などを踏まえながら、どの情報が確定していて、何が未整理なのかを明確にしていきました。
また、要件がなかなか決まらない場面では、待つだけではなく、こちらから案を積極的に提示することで、議論が前に進むように工夫していました。
単に確認事項を並べるのではなく、判断しやすい材料を提示していくことも、この案件では重要な役割でした。
blueの対応2:設定代行ではなく、業務設計のサポートまで踏み込んだ
今回の案件でblueが担ったのは、楽楽販売の設定代行だけではありませんでした。
blueでは、要件定義フェーズから保守まで関わり、業務や要件を楽楽販売の仕様に照らし合わせながら調整し、設計・開発・運用の実現まで支援しています。
今回、特に大きかったのは、業務設計のサポートに踏み込んだことです。クライアント側では、業務が多岐にわたり、かつ縦割りで整理されているため、自分の関わる範囲以外の知見が十分でないこともあり、全体でフローを設計していくことに難しさがありました。
blueは、こうした状況に対して、システム仕様を踏まえながら業務や要件を再整理し、現場が運用可能な形へ落とし込んでいきました。
スケジュールが厳しい中でも、業務担当者レベルにも寄り添いながら、プロジェクト推進側と実務側の間に入り、軋轢を最小限にしつつ前へ進めていった点は、この案件における大きな価値だったと考えられます。
つまりblueは、単に「作る会社」ではなく、プロジェクト全体が進むために必要な整理と調整を担うパートナーとして機能していました。
blueの対応3:仮案やプロトタイプを起点に、曖昧な要件でも前進させた
要件が曖昧な案件では、会議を重ねるだけでは決まりにくいことがあります。
そこで今回のプロジェクトでは、仮の案やプロトタイプを用意し、議論の軸をつくったうえで、そこから広げたり深めたりする進め方を取っていました。
ドキュメントも、できるだけ具体的にイメージできるように詳細に作成し、クライアントが確認・回答すべきことを簡潔に区切って整理しました。
部署によってMTGや要件調整の進め方も変えながら、認識合わせの精度を高めていきました。
また、多少の手戻りは覚悟したうえで、すでに決まっている部分から固めて進めるという判断もしています。
すべてが確定してから着手するのではなく、前へ進めながら曖昧な論点を減らしていくやり方は、スケジュールが厳しい大規模案件では特に重要です。
このように、blueは「要件が決まらないから止まる」のではなく、「決まりにくい要件でも前進できる状態をつくる」ことに注力していました。
導入後も終わらない。保守・改善フェーズまで支援
この案件は完了後もそこで終わらず、現在は2次フェーズが進行しており、追加相談や改善対応も継続しています。
導入後には、旧基幹システムではできなかったことが新たに可能になったことで、クライアントにも業務効率化を実感していただけました。また、複数システムをまたぐ二重入力が大きく減ったことも、現場にとって大きな変化のひとつです。
クライアントからは、blueのプロジェクト対応に対して高い評価をいただいており、運用が安定した後も、「こんなこともできるのでは」「こういう使い方もしたい」といった追加のご相談をいただくようになりました。
こうした相談が継続していることは、単にシステムを導入しただけではなく、稼働後も安心して相談できるパートナーとして信頼いただけていることの表れだと考えています。
現在も保守やエンハンス対応が続いており、今後は別部署の業務を楽楽販売へ移行する予定もあります。
つまりこの案件は、1回きりの導入ではなく、継続的に改善しながら業務を広げていくプロジェクトとして発展しているのです。
まとめ:大規模な基幹業務リプレイスで重要なのは、システム理解と業務理解をつなぐこと
今回のプロジェクトから見えてくるのは、基幹業務のリプレイスでは、単にシステムを置き換えるだけでは不十分だということです。
特に、複数部署にまたがる販売管理業務では、それぞれの業務理解、部署間調整、既存システムやExcel運用の整理、スケジュール管理まで含めて進める必要があります。
そのため、楽楽販売の設定スキルだけでなく、業務理解とプロジェクト推進の両方に対応できるパートナーが重要になります。
blueは、要件定義から開発、保守まで広い範囲で伴走し、曖昧な要件や複雑な調整がある中でも、現場に寄り添いながらプロジェクトを前進させてきました。また、稼働後の改善や別部署展開まで見据えて関わっている点も、この案件の大きな特徴です。
もし今、
- 複数部署や複数システムが絡む販売管理業務を整理したい
- 旧基幹システムやExcel運用からリプレイスしたい
- システム導入だけでなく、業務整理や要件調整から支援してほしい
- 導入後の保守やエンハンスまで任せられるパートナーを探している
という課題があれば、まずは現状業務と論点を整理するところから始めることが重要です。大規模なプロジェクトほど、寄り添いながら前進させる支援が成果に直結します。
よくある質問
基幹業務のリプレイスや、複数部署の販売管理整理でお悩みの方へ
大規模な販売管理リプレイスでは、システムの設定だけでなく、複数部署にまたがる業務理解や調整、運用設計が成功の鍵を握ります。特に、旧基幹システム、Excel、他システムが混在している場合は、単に置き換えるだけではなく、現場で回る形へ整理することが欠かせません。
blueでは、楽楽販売の導入支援に加え、要件定義、業務整理、プロジェクト推進、保守・エンハンス対応まで含めた伴走支援に対応しています。「大きな案件を一緒に前へ進められるパートナーを探している」という段階からでも、お気軽にご相談ください。
編集・執筆:blue広報チーム
取材協力・監修:blue DXチーム
ゼロから一緒に考える!並走型アジャイル開発の進め方
採用サイトリニューアルで差がつく!Z世代に届く最新トレンド5選と成功事例まとめ
楽楽販売API連携でできること|受注〜請求の自動化と基幹・EC連携事例
私からひとこと②モチベーションは必要ない。必要なのは…
私の生成AIは「チャッピー☺️」 チャッピーと友達になったら、仕事も人生も捗りすぎた話
「何を確認すればいい?」の不安が消える。NotebookLMで案件の解像度を爆上げした若手ディレクターの話
Figmaで簡単再現!Liquid Glassデザインに挑戦!
Figma to Codeプラグイン、実際どうなの?ワーママデザイナーが試してみた記録とレビュー
Flutter vs React|アプリ開発の技術選定で押さえるべきポイント