受注管理システムはクラウドか自前か｜判断軸と中間の選択肢

受注管理システムの導入はクラウドサービスを利用するか、自前でシステム保有するかの二つの選択肢があります。どちらにもメリットデメリットがあります。カスタマイズがどこまで必要かということだったり、今現在だけでなく将来のコスト感はどうなりそうか。また自社内の開発や業務理解などに対する知見の有無などを判断軸で、選択する必要があります。

クラウドサービス利用か自社開発か

受注管理システムを導入するということは、クラウドサービスを導入するか、自分たちで作ったり開発ベンダーと連携して自社でシステムを持つかという選択を迫られることになります。例えば小規模事業だと、それほど開発コストをかけることができないために、ランニングコストを支払うことでクラウドサービスを利用するという選択肢をする企業が多いです。それほど現場のクラウドサービスはクライアントニーズを満たしたものと言い換えることもできます。

クラウドサービスを利用するということはどういうことか

メリット

まずは固定資産を抱える必要がないという点です。また自社システムではないなので保守修繕などのコストもかかりません。不具合があったとしても自分たちで対応する必要がありません。また受注管理システムは多くの業界や企業に利用される前提で作られているため、比較的重要度の高そうな機能は、最初からついていることが多いというメリットもあります。

デメリット

一方でカスタマイズ性が乏しい可能性もあります。自分たちはこういう情報を大切にしたいと思っても、その情報は取り扱うことができないという制限がある可能性があります。またIDに応じた課金のため想定以上に企業規模が大きくなると、思わぬコストを支払わねばならない可能性もあります。

また受注情報は業務の根幹に当たる部分でもあります。つまり受注管理システムありきの業務フローが組まれてしまう可能性が高いということです。ということはもし仕様変更があれば、それに伴い自社の業務フローを大きく変更しなければならないという可能性もあります。

それほど事業の根幹に位置付けられるものなので、もし仮にシステム提供企業の倒産や、業績不振によるサービスストップなどがあれば、かなり大掛かりな業務フローの変更を強いられる可能性があります。そしてID課金の値上げを要求されても、業務フローを変えられないので飲まざるを得ないという苦しい状況を生み出すこともあります。

自前の受注管理システムを持つということはどういうことか

メリット

まず自前で受注管理システムを持つことによる一番のメリットは自由な追加開発やカスタマイズが可能になるため、経営をする上で必要な情報は、自らの判断で決定できるという点にあります。また人数が増えたとしても機能が増えない限りは基本的にシステムそのものの大きさが変わる話ではないため、固定費としての保守修繕の額が跳ね上がるわけではありません。

また自社の他システムとの連携も可能というメリットがあります。つまりクラウドサービスだと、自社システムと連携できなかったり連携できたとしても、追加コストがかかるという可能性もあります。

デメリット

自前システム最大のデメリットは、最初の段階でのコスト負担が大きすぎる点にあります。機能を最小限に絞ったとしても最低でも100万円前後かかるでしょうし、社内のエンジニアに作ってもらうにしても、何人月かはそれにベタばりさせなければなりません。またクラウドサービス以上のセキュリティを担保しようとすると、それもコスト高の要因になります。

一番のデメリットは、システム開発やプロジェクトマネージャの業務理解度に応じたクオリティになってしまうということです。営業経験のなく業務理解が浅いプロジェクトマネージャが作った受注管理システムは、現場的に必要なものが抜け落ちている可能性が高いです。

逆に営業出身者をプロジェクトのリーダーに指名すると、開発側の状況を理解できずに、積み木を上まで積み上げてから「一番下の積み木を動かしたい」というような揺り戻しが起こる可能性もあります。

自社内で内製する場合は、出来上がればまだマシかもしれず、最悪プロジェクトが頓挫し、モノができないとか現場の反発やアレルギーが強すぎて、導入できないということもありえます。

受注管理システムの判断軸

どちらにもメリット・デメリットありますが、結局は何らかの形で受注システムを持たなければならないわけです。そうした時にどのようなものが判断軸として機能するのでしょうか？それは下記のようなものになります。

• 事業規模の大きさ
• 事業規模の成長見込み
• 自社の業務理解度や企画機能の強さ
• 自社のシステム開発知見

事業規模の大きさ

まず現時点で既に一定規模の事業規模が大きくなってしまっているのであれば、結論としては自社で持つべきです。例えば今までシステムを既に使っていて、あまりに不便で乗り換えを検討しているようなタイミングです。そこから別のクラウドサービスに乗り換えることを検討しているのであれば、そのタイミングで自前でシステムを持つことがベターでしょう。ID課金ですのであまりに月額の支払いが高くなってしまいます。今のシステムよりは安くなるとしてもです。

事業規模の成長見込み

事業規模が今後極めて早いスピードで成長する見込みがあるのであれば、最初から自社でシステムを持つべきでしょう。これも同じ理由で将来のコスト負担があまりに大きくなってしまう可能性があるためです。もし見込んでいたほどの成長が実現できなかったとすれば、結果的にコスト高になってしまう可能性はありますが、そこは未来予測を誤ったのですから飲み込むしかありません。

自社の業務理解度や企画機能の強さ

自社で末端のメンバーから経営層までの業務の全貌を理解している人がいるでしょうか？または理解するだけのスキルを持っている人はいるでしょうか？先述したように受注管理システムは事業の根幹を担うシステムになります。それがある前提で諸々の業務フローが組まれるため、現場の利便性と経営情報の過不足、加えてバックオフィスのオペレーションまでをもスコープにして検討する必要があります。そういった企画機能を自社で調達できないのであれば、自社でシステムを持つことは危険です。リスクが低いクラウドサービスを利用する方がよいでしょう。

自社のシステム開発知見

また自社で開発しようが、開発会社に発注しようが、どちらの場合においても、自社内にシステム開発知見がないままに動かすことはあまりに危険です。というのは、業務フローに深く深く組み込むシステムなので後戻りができないのです。一回作ってしまい実装をして、業務フローに組み込んでしまうと、そこからの撤退コストやスイッチングコストは極めて割高になります。

ベンダーに任せっきり、仕様書や要件定義書もよくわかっていない。提案されたことのyes/noジャッジをするのが精一杯という状態で、自社システムを持つことは諦めた方が良いでしょう。もしそういう状態でどうしても自社システムを持つ必要があるのであれば、開発ベンダーとは別に業務フロー構築とシステムに強いコンサル会社に別で発注し、自社、コンサル、ベンダーの三社でプロジェクトを組み、コンサルにリードをしてもらうのが一番よいでしょう。逆に将来を見越した時に、そこまでした方がよいほど、受注管理システムというのは重要な機能ということです。

営業の現場では、受注管理システムへの理解が成果を大きく左右します。本記事で紹介したポイントを振り返り、明日からの業務に少しずつ取り入れていきましょう。

実は「二択」ではない──あいだにある選択肢を知る

クラウドを借りるか、自前で作るか。こう問われると、どちらか一方を選ぶ話に聞こえます。しかし現実には、この二つの極のあいだに、いくつものグラデーションがあります。まず、その中間の選択肢を知っておくと、判断の幅が広がります。

たとえば、カスタマイズ可能なクラウドサービス。基本は既製のクラウドを使いつつ、自社に必要な部分だけを設定や拡張で作り込む、という折衷案です。あるいは、ローコード・ノーコードのツールを使えば、専門のエンジニアがいなくても、自社の業務に合わせた仕組みをある程度は自分たちで組めます。さらに、複数の既製サービスをAPIでつなぎ合わせ、全体として自社に合った形を作る、という手もあります。考え方の軸は、「全部借りる」か「全部作る」かの極端に振れないことです。自社の競争力に直結する部分はこだわって作り込み、どの会社も同じような汎用的な部分は潔く借ります。この切り分けができると、「クラウドか自前か」という重い二択が、「どこを借りて、どこを作るか」という、もっと現実的で柔らかい設計の問題に変わります。まずは、選択肢は二つではない、と知ることが出発点です。

自前で作る、最大の落とし穴──「今のやり方」をそのまま固める

自前開発のリスクとして、作り手の業務理解の浅さが指摘されていました。ただ、業務を深く理解している人が作れば安心かというと、そこにもう一つ、見落とされがちな罠があります。それは、「今のやり方」を、そのままシステムに固めてしまうことです。

システムを自前で作るとき、多くの現場は「今こうやっているので、その通りに作ってください」と要望します。一見、正しいように見えます。しかし、これをやると、非効率な現状の業務フローが、多額のコストをかけて、変えられない形で固定されてしまいます。本来、システムを作るという作業は、業務を根本から見直す、またとない機会です。「この承認ステップは本当に必要か」「この二重チェックは何のためか」を問い直し、ムダを削ってから作れば、システムは業務改善そのものになります。ところが、現状の再現を目的にすると、せっかくの機会が、非効率の温存に変わってしまいます。作る前に、一度立ち止まって「そもそも、この業務フローは最適なのか」を問います。システム化は、業務改善とセットにして初めて、本当の価値を生みます。今のやり方を疑わずに作り込むほど、後で「作り直したいのに、業務に組み込まれていて動かせない」という、最も避けたい事態を招きます。

どちらを選んでも、「移行」で失敗する

技術選定と判断軸ばかりに目が行きがちですが、実は多くのプロジェクトが、選定ではなく「導入・移行」の段階でつまずきます。どんなに正しいシステムを選んでも、乗り換えの進め方を誤れば、現場は混乱し、最悪の場合、使われないまま終わります。

押さえるべきは三つです。一つ目は、一気に全社を切り替えないことです。まず一部門や一部の業務で小さく始め、問題を洗い出してから広げます。全部を同時に切り替えると、トラブルが起きたときに逃げ場がありません。二つ目は、データ移行を甘く見ないことです。旧システムや既存のデータを新しい形に移す作業は、想像以上に手間がかかり、ここでの不備が後々まで尾を引きます。三つ目、そして最も大事なのが、現場を巻き込むことです。現場の反発やアレルギーが強すぎて導入できない、という失敗に触れられていましたが、これは移行の進め方で大きく防げます。決める段階から現場の声を聞き、なぜ変えるのか、変えると自分たちがどう楽になるのかを丁寧に伝えます。使う人が納得していないシステムは、どれだけ高機能でも根付きません。技術を選ぶことと同じくらい、人を動かす移行の設計に力を注ぐ必要があります。

そもそも、決断とは「正解を当てる」ことなのか

ここまで、中間の選択肢、自前開発の罠、移行のリスクを見てきました。最後に、「クラウドか、自前か」という決断そのものの本質を、考えてみたいと思います。

この決断が難しいのは、受注管理が業務の根幹に組み込まれ、一度決めたら後戻りができない――撤退やスイッチングのコストが、極めて高くつくからだと、繰り返し語られていました。ここに、システム選定の、そして多くの重要な決断に共通する、本質が隠れています。私たちはつい、決断とは「最適な正解を一発で当てること」だと思い込みます。事業規模を予測し、成長を見込み、最もコストの合う選択肢を選びます。しかし、どれだけ精緻に考えても、未来は読めません。事業は予想を超えて伸びることもあれば、見込みほど育たないこともあります。前提が外れれば、最適だったはずの選択は、たちまち重荷に変わります。クラウドのロックインで値上げを飲まされるのも、自前開発が頓挫するのも、突き詰めれば「一度決めたら引き返せない」という構造から生まれる痛みです。

だとすれば、賢い決断とは、正解を一発で当てることではありません。「間違えたときに、どれだけ引き返せるか」という、可逆性を確保しておくことです。問うべきは、「クラウドか自前か、どちらが正解か」だけではありません。「この選択は、後で状況が変わったとき、どれだけ変更できる余地を残しているか」を、判断軸に加えるべきなのです。具体的には、データは自社の手元に、標準的な形式で持っておきます。一気に全部を一つの選択に賭けず、段階的に進めます。うまくいかなかったときの撤退ラインを、決める前にあらかじめ引いておきます。こうした構えは、未来を正確に予測しようとするのではなく、「予測が外れても致命傷にはしない」ための設計です。

不確実な未来に対して、私たちにできるのは、正解を見通すことではなく、間違いのコストを管理することです。完璧な選択を求めて決断が止まるより、そこそこ良い選択を、引き返せる形で素早く実行するほうが、たいていうまくいきます。決断とは、正しさを追い求めることである以上に、間違えたときのダメージをあらかじめ小さく設計しておくことです。この視点を持てると、「どちらが正解か」で身動きが取れなくなる代わりに、「どちらを選んでも、後で立て直せるようにしておこう」と、前に進めるようになります。後戻りできないものだからこそ、後戻りの余地を残して決めます。それが、重い決断と付き合うための、最も現実的な知恵なのだと思います。

あわせて読みたい

• クラウドの受注管理システムでできること｜機能表の先を読む──クラウドの利点、定着する運用、つないで効く一元化
• 夜が明けてAIの一日が始まった時、僕はChatGPTと商談解析を始めた
• 人間ができることとAIができることそしてAIを使って営業組織に対して僕ができること
• AIが“持たざる営業組織”ほど救う話
• クラウドサイン的なサービスを申し込んだら紙の申込書が送られてきたでござる