Core System基幹システムの刷新・入れ替え支援

Consultationこんなご相談から始まっています

---

販売管理を入れ替えたいが、何から手を付ければいいか分からない

ベンダーの見積が妥当かどうか、社内で判断できない

前回の導入でうまくいかなかった。同じ轍を踏みたくない

使っているシステムのサポートが終わると言われた。何年後を目標にすればいいのか

入れ替えたほうがいいのかどうか、そもそも判断がつかない

Timing「そろそろ入れ替え」の判断は、いつすべきか

---

ご相談としていちばん多いのが、実はここです。壊れてはいない。でも、このままでいいのかも分からない。 判断のきっかけになるのは、だいたい次の5つです。

• メーカーのサポートが終わる｜期日が決まっているぶん、いちばん動きやすい理由です。ただし「サポートが切れる＝すぐ止まる」ではありません。慌てて決めると高くつきます
• 導入したときを知っている人が、社内に誰もいない｜なぜその設定になっているのかが分からない状態です。これは年数よりも危険な兆候だと考えています
• システムに合わせるために、手作業が増えている｜Excelでの転記、二重入力、紙に印刷してから確認。入れ替えの効果がいちばん大きいのは、この状態の会社です
• 業務が変わったのに、システムが変わっていない｜商流や販路が増えたのに、10年前の前提のまま運用しているケース
• 維持費が、新しく入れる費用に近づいてきた｜保守費とカスタマイズ費の累計を、一度出してみてください

逆に、まだ入れ替えなくていい場合

• 手作業が発生していない｜年数が経っていても急ぐ必要はありません
• 業務のほうが固まっていない｜先に業務を決めてください。決まっていない業務をシステムに固定すると、入れ替えた直後にまた作り直しになります
• 入れ替えの目的が「古いから」だけ｜目的が定まるまで待ったほうがいいです

弊社は、この診断だけのご依頼も承っています。「まだ早いです」という結論になることもあります。それも結論のひとつです。

Failure刷新が失敗する原因は、だいたい決まっています

---

このテーマで最も多く聞かれている質問が「システム導入の失敗の原因は」です。それだけ、失敗した会社が多いということでもあります。現場で見てきた範囲では、原因は次の4つに集約されます。

1. 現行踏襲

「いまと同じことができるように」から始めると、いまの業務の複雑さを、そのまま新しいシステムに移植することになります。費用は膨らみ、使いにくさも引き継がれます。入れ替えは、業務をやめる数少ない機会です。

2. 要件を、決める人が決めていない

現場から出た要望をそのまま積み上げると、要件は必ず膨らみます。取捨選択できるのは、業務をやめる権限を持っている人だけです。経営が関与しないプロジェクトは、ここで止まります。

3. ベンダーに主導権を渡してしまう

こちらが何をしたいのか整理できていないと、提案の良し悪しを判断できません。判断できないまま進むと、決めているのはベンダーという状態になります。悪意の話ではなく、判断材料を持っている側が決めるのは自然なことです。

4. 入れて終わりにする

稼働日がゴールになっているプロジェクトは、稼働後に誰も面倒を見ません。現場が使えるようになるまでが導入です。

責任は誰にあるのか

率直に書くと、発注側の責任である場合が多いです。要件を決めきらなかった、途中で変えた、決裁が下りるのが遅れた。ベンダーの見積が甘かったケースももちろんありますが、原因の多くは契約の前段階にあります。 だからこそ、弊社は選定の前、要件を整理する段階から入ります。

Do / Don’tやることと、やらないこと

---

KEEP｜御社に残していただくこと

• 要件の優先順位を最終的に決めること｜弊社は選択肢と根拠を出します。何をやめるかを決めるのは経営です
• 稼働後、誰が使い方を教えるか｜ここを外に出すと、いつまでも定着しません。社内に1人は必要です

Vendorベンダー選定を、主役として扱います

---

システム刷新の解説記事を10本ほど読み比べましたが、ベンダー選定はどれも「進め方の第3ステップ」として一段落だけ触れられていました。実際には、ここで決まります。

評価項目を、先に決めます

提案を見てから評価軸を決めると、印象が良かった会社に合う軸ができあがります。提案を受け取る前に、何を何点で見るかを決めておきます。弊社が使う軸は、おおむねこの6つです。案件によって重みを変えます。

• 業務適合｜自社の業務が、カスタマイズなしでどこまで乗るか
• 費用｜初期費用だけでなく、5年間の総額で比べます
• 移行｜いまのデータをどう持っていくか。ここを軽く見た見積は必ず膨らみます
• 体制｜担当者が誰か。何人か。その人は他に何件抱えているか
• 稼働後｜保守の範囲と、追加開発の単価。契約前に文書で取ります
• 撤退可能性｜やめるとき、データを取り出せるか

何社に声をかけるか

多すぎると比較しきれず、少なすぎると相場が分かりません。3社が扱いやすい数です。2社だと比較になりにくく、5社を超えると評価の工数が現実的でなくなります。1社だけ「本命」がいる場合でも、比較対象は用意したほうがいいです。

同席します

ベンダーとの打ち合わせに、御社側の人間として同席します。専門用語のまま話が進んでいるとき、その場で止めます。「いま言われたことは、こういう意味です」を、その場で言える人がいるかどうかで、出てくる見積が変わります。

RFPRFPは、社内で書けなくて普通です

---

RFP（提案依頼書）は、ベンダーに「これを作ってください」と伝えるための文書です。提案依頼書、要求仕様書とも呼ばれます。 よく聞かれるのが「RFPは誰が書くのか」ですが、発注側が書くものです。とはいえ、書ける会社のほうが少ないです。自社の業務を文章で説明した経験がある人は、そう多くありません。

RFI・RFP・RFQ の違い

• RFI｜情報提供依頼。どんな選択肢があるか、市場を知るために出す
• RFP｜提案依頼。要件を示して、提案と見積を求める
• RFQ｜見積依頼。仕様が固まったあと、金額だけを求める

順番はRFI、RFP、RFQ。ただし中小企業の案件では、RFIを省いてRFPから始めることが多いです。選択肢がある程度絞れているなら、その方が早く進みます。

要件定義とは違います

RFPは「何をしたいか」、要件定義は「どう作るか」です。RFPの段階で作り方まで書くと、ベンダーの提案の幅を自分で狭めることになります。やりたいことと、譲れない条件を書く。作り方はベンダーに考えてもらう。この分担が基本です。

弊社の関わり方

御社の代わりに全部書く、という形にはしていません。業務のことを一番知っているのは御社だからです。弊社は現場ヒアリングをして構成を作り、たたき台を書き、御社に確認していただきながら仕上げます。作成期間はおおむね1〜2か月です。

Cost費用と期間の考え方

---

何で決まるか

システム刷新の費用は、機能の数ではなく次の4つで動きます。

• 業務範囲｜販売管理だけか、在庫・生産・会計まで含むか
• カスタマイズの量｜パッケージに業務を合わせるほど安く、逆ほど高くなります
• データ移行｜過去何年分を、どこまで整えて持っていくか。見落とされがちで、いちばん膨らむ項目です
• 並行稼働の期間｜新旧を同時に動かす期間があるほど、現場の負荷と費用が増えます

5年で比べてください

初期費用だけで比べると、判断を誤ります。初期費用＋5年分の保守費＋想定される追加開発費で並べてください。初期が安く保守が高い提案と、その逆があります。5年で見ると順位が変わることがあります。

期間の目安

規模によりますが、検討開始から稼働まで1年前後を見ておくのが現実的です。このうち、要件整理とベンダー選定に3〜6か月かかります。サポート終了が理由の場合は、期日から逆算して1年半前には動き始めてください。

弊社の費用

プロジェクトごとに、月10万円からです。 「1件の入れ替えプロジェクトに、月いくら」という数え方をしています。販売管理の入れ替えと、並行して別の仕組みの検討も、という場合は、それぞれ別のプロジェクトとしてお見積りします。どちらも中途半端になるより、分けたほうが結果的に早く終わるためです。 選定支援の場合、要件整理からベンダー選定まででおおむね3〜6か月を見ています。導入・定着まで伴走する場合は、稼働後も同じ形で続きます。 現状診断だけのご依頼も承っています。この場合は1か月で完結する形にしていますので、月10万円です。「そもそも入れ替えるべきかどうか」だけ知りたい、という段階の方はここから入ってください。「まだ早いです」という結論になることもあります。

弊社の費用と、システムの費用は別です

念のため書いておくと、上の金額は弊社の支援費用です。システムそのものの費用は、導入するベンダーへのお支払いになります。その金額は、前述の4つ（業務範囲・カスタマイズの量・データ移行・並行稼働の期間）で決まります。 弊社は、その見積が妥当かどうかを御社側で見る立場です。

Process進め方

---

• 01現状診断データを見せてもらい、手作業の順番を書き出します。この段階で「まだ入れ替えなくていい」となることもあります
• 02要件整理現場と経営の両方の要望を聞き、優先順位を付けます
• 03RFP作成提案依頼書のたたき台を作り、御社と仕上げます。おおむね1〜2か月
• 04選定・交渉評価表と推奨案を出し、ベンダーとの折衝に同席します
• 05導入・定着現場の熟練度が上がるまで伴走します

Neutrality受け取らないもの、やらないこと

---

比較や選定のお手伝いをする立場で、候補に挙げた会社から紹介料をもらっていたら、比較になりません。選定支援に入る案件については、選定対象となるベンダーからの手数料を受け取らない。ここに例外は作りません。 なお、弊社は一部の商材について販売代理店としての手数料を受け取っています。そのため「ベンダーから一切受け取らない」とは書きません。書けないことは書きません。該当する商材がある場合は、提案の時点でお伝えします。

システム開発そのものは受託しません

「このシステムを入れましょう」と言った人間が、そのまま開発を請けると、規模を大きくするほど自分の売上が増えます。構造として中立でいられないので、開発は受託しません。実装が必要な場合は、御社と開発会社が直接契約する形にして、弊社は御社側で仕様と見積を見る立場に入ります。 この2つを書いているのは、きれいごとを言いたいからではありません。中立だと口で言うのは簡単で、判断できるのは収益構造だけだからです。だから、収益の形のほうを書いています。情シス代行でも同じ考え方でお受けしています。

Facts実績

---

• 株式会社ヒューマンフォーラム様（SPINNSほかを展開、90店舗超）：販売管理システムを約5年かけて全社に定着させ、後継システムの選定まで伴走。情報システム部門そのものは2017年11月から継続して担当しています
• 金属加工グループ様：生産管理システムの運用を定着させ、発注データの手入力をゼロに
• 文具メーカー様：倉庫管理システム（WMS）の導入を支援しています

この領域の実績を見る →

FAQよくあるご質問

---

基幹システムとERPは何が違うのですか？

基幹システムは、販売・在庫・生産・会計といった、事業の中核を担うシステムの総称です。ERPはそれらを1つのパッケージに統合した製品を指します。ERPは基幹システムの一形態、という関係です。必ずしも統合されている必要はなく、分かれていて連携できていれば問題ありません。

基幹システムは何年くらいで入れ替えるものですか？

一律の年数はありません。判断材料になるのは、年数よりも「導入時を知る人が社内にいるか」「システムに合わせるための手作業が増えているか」の2つです。サポート終了が決まっている場合は、期日の1年半前から動くことをおすすめします。

刷新しないほうがいい場合はありますか？

あります。手作業が発生していないなら急ぐ必要はありませんし、業務のほうが固まっていない場合は、先に業務を決めるべきです。弊社は現状診断だけのご依頼も承っており、「まだ早いです」という結論をお伝えすることもあります。

費用はどれくらいかかりますか？

弊社の支援費用は、プロジェクトごとに月10万円からです。選定支援の場合、要件整理からベンダー選定までおおむね3〜6か月を見ています。現状診断だけのご依頼は1か月で完結する形にしています。 システムそのものの費用は別で、こちらは導入するベンダーへのお支払いになります。業務範囲、カスタマイズの量、データ移行の範囲、並行稼働の期間で変わります。初期費用だけでなく、5年分の保守費と追加開発費を含めて比較してください。

RFPは誰が書くのですか？

発注側が書くものですが、書ける会社のほうが少ないです。弊社は現場ヒアリングをして構成を作り、たたき台を書き、御社に確認いただきながら仕上げる形にしています。作成期間はおおむね1〜2か月です。

ベンダーは何社に声をかけるべきですか？

3社が扱いやすい数です。2社だと比較になりにくく、5社を超えると評価の工数が現実的でなくなります。

導入するシステムを、御社が開発してくれるのですか？

いいえ。システム開発そのものは受託していません。「これを入れましょう」と言った人間が開発も請けると、規模を大きくするほど自社の売上が増えるためです。実装は御社と開発会社の直接契約にしていただき、弊社は御社側で仕様と見積を見る立場に入ります。

複数の案件を同時に見てもらうことはできますか？

できますが、プロジェクトごとに分けてお見積りします。まとめて1本にすると、どちらも進みが遅くなります。優先順位を決めて、片方から着手するご提案をすることもあります。

途中から相談してもいいですか？

構いません。ベンダーから提案が出た段階で「この見積が妥当かどうか見てほしい」というご相談もよくいただきます。契約前であれば、まだ選び直せます。