3年後、「顧客」と「商品」は同じ意味ですか？
3年前、この会社にとって「顧客」は、商品を買ってくれる会社でした。
「商品」も明確でした。仕入れた機械を法人顧客に販売する。営業が見積を出し、受注したら納品し、月末に請求する。
- 顧客は「買ってくれる会社」
- 商品は「販売するモノ」
- 営業は「売る人」
- 売上は「納品した金額」
だからシステムも、その商売に合わせて作りました。顧客マスターがあり、商品マスターがあり、見積、受注、出荷、売上、請求へと流れていく。
当時としては、よくできたシステムでした。
問題は、システムが間違っていたことではありません。
会社のほうが、その後も動き続けたことです。
最初に、「顧客」が変わった
直販だけだったところに、代理店販売が加わりました。
すると、それまで当たり前だった「顧客」という言葉が少し怪しくなります。
商品を販売する相手は代理店ですが、実際に使うのはその先の企業です。契約する会社、請求する会社、製品を使う会社が同じとは限らなくなりました。
では、顧客マスターに登録する「顧客」は誰なのか。
そこで「利用企業」という項目を追加しました。
しばらくするとECも始まります。
今度は営業担当者を介さず、顧客が直接注文します。価格体系も違えば、値引き、在庫引当、キャンセル、返品、手数料の扱いも違う。
ECは別システムで管理し、販売管理システムへデータを連携することになりました。
この段階では、まだ対応できます。
次に、「商品」が変わった
会社は、機械を売って終わりではなく、保守サービスも提供するようになりました。
すると、これまでの「商品」という考え方だけでは足りなくなります。
機械には納品日がありますが、保守には契約開始日と終了日があります。更新もあれば解約もある。
そこで商品マスターに「サービス区分」を追加し、契約期間を管理する仕組みも加えました。
さらに製品にセンサーを付け、利用状況を取得するサービスを始めました。ソフトウェアも提供するようになり、月額課金も始まります。
ここまで来ると、改めて妙な質問が出てきます。
「商品って、どこまでを商品と呼びますか？」
- 機械なのか
- 保守なのか
- ソフトウェアなのか
- 利用権なのか
- それとも、それらを組み合わせた契約全体なのか
3年前には疑う必要すらなかった「商品」という言葉の意味が変わっています。
売上の意味まで変わってくる
売り切りの商売では、「いくら売ったか」が重要でした。
しかし月額サービスでは、それだけでは商売の状態が分かりません。
- 誰が使っているのか
- どの程度利用しているのか
- いつ更新されるのか
- 継続してもらえそうなのか
100万円の機械を一度売ることと、月額10万円のサービスを継続して利用してもらうことでは、同じ売上金額でも商売として見たいものが違います。
つまり、商品が変わることで、会社が管理すべき「事実」まで変わります。
さらに料金体系も変わるかもしれません。
一個いくら、だけではありません。
- 月額いくら
- 利用人数に応じていくら
- 場合によっては成果に応じていくら
商売の単位そのものが変われば、受注、売上計上、請求、更新、解約まで、それまで当たり前だった処理の前提が変わってきます。
そして、「営業」も変わった
商売が変われば、組織も黙ってはいません。
- 地域別だった営業組織を業界別に変更する
- ECはマーケティング部門へ移管する
- 継続サービスが増え、カスタマーサクセスという、それまで存在しなかった役割を作る
すると、以前は合理的だった業務ルールまで現実と合わなくなります。
- 営業担当者が入力する
- 営業事務がチェックする
- 課長が承認する
- 部長が決裁する
その時点では、どれも正しいルールでした。
- しかし組織変更で課長職がなくなった
- 営業事務は本社に集約された
- ECにはそもそも営業担当者がいない
さらに、人がチェックしていた仕事の一部をAIで処理するようになれば、「誰が入力し、誰が確認するのか」という人間の役割分担を前提にした設計まで変わります。
会社の組織図はとっくに変わっています。
それでもシステムの中では、3年前の会社が営業を続けています。
会社の境界さえ変わる
変わるのは、商品や組織だけとは限りません。
事業が成長して子会社を作ることもあります。M&Aで別の会社が加わることもあれば、逆に一つの事業を売却することもあります。
すると、それまで「会社は一つ」と考えていたシステムに、法人をまたいだ取引や在庫、顧客情報の共有といった話が入ってきます。
3年前には「会社コードなんて一つでいい」と考えることに、何の不自然さもなかった。
それさえ、経営判断一つで変わります。
競争相手まで変わる
さらに厄介なのは、自社だけが変わるわけではないことです。
これまで競合だと思っていたのは、同じような機械を売っている同業他社だった。
ところが顧客から見れば、別業界から登場したサービスで同じ目的を達成できるようになることがあります。
すると経営者は、「この商品をどう売るか」ではなく、
「そもそも私たちは、何を商品としている会社なのか」
から考え直すことになります。
商品を変える。顧客との関係を変える。売り方を変える。組織を変える。場合によっては、会社そのものを変える。
これは特別な会社だけに起こる話ではありません。
経営するということ自体が、こうした前提を変え続けることでもあります。
そのたびに、システムも直してきた
もちろん、会社も何もしてこなかったわけではありません。
- 代理店販売が始まったので、顧客マスターに項目を追加した
- 保守サービスを始めたので、契約管理機能を追加した
- ECを始めたので、別システムと連携した
- 組織変更があったので、承認フローを変更した
月額サービスだけ既存システムでは扱いにくいので、Excelで管理する。
一つひとつを見れば、合理的です。
誰かが間違った判断をしたわけではありません。
しかし、それを何年も続けているうちに、こんな話が出てきます。
- 「この項目を変えると、どこに影響するのか分からない」
- 「この処理は、なぜこうなっているんだっけ」
- 「新しいサービスを始めたいけれど、システム改修に半年かかる」
会社が変わるたびに、その変化をシステムへ継ぎ足してきた結果です。
古くなるのは、プログラムだけではない
システムの老朽化というと、古いプログラミング言語、古いデータベース、サポート期限を迎えるOSなどを想像します。
もちろん、それらも問題です。
しかし、もう一つ厄介な老朽化があります。
「前提」の老朽化です。
- 顧客とは誰なのか
- 商品とは何なのか
- 一件の取引とは何なのか
- 誰が何を担当するのか
- どこまでを一つの事業として扱うのか
システムを作ったときには正しかったこれらの前提が、経営の変化によって少しずつ現実から離れていきます。
会社が変わり続けた結果、システムが前提としている会社と、現実の会社が別物になってしまう。
つまり、システムの寿命を決めるのは技術の古さだけではありません。
そのシステムが前提としている「会社」の古さです。
会社は変えるのに、なぜITだけ「完成」させようとするのか
ここで少し不思議なことがあります。
経営者は、会社が変わることを知っています。
新しい商品を作る。価格を変える。販売チャネルを増やす。組織を変える。新規事業を始める。会社を買うこともあれば、事業を売ることもある。
ところがシステム刷新になると、
「長く使えるシステムを作りたい」
という話になります。
もちろん、長く使えること自体が悪いわけではありません。
問題は、何をもって「長く使える」と考えるかです。
今の業務を隅々まで正確に再現し、それを長く使い続けることが長寿命なのでしょうか。
それとも、会社が変わったときにシステムも変えられることが長寿命なのでしょうか。
商品も顧客も組織も変える会社が、ITだけには「完成形」を求める。
そこには、少し矛盾があります。
経営者が手に入れるべきなのは、「完成品」ではなく「構造」
ここでいう「構造」は、システムの専門用語としてのアーキテクチャだけを指しているわけではありません。
会社を一つの建物として考えてみます。
商品が変わる。顧客が変わる。売り方が変わる。組織が変わる。
それは建物でいえば、売り場や間取り、内装、そこで働く人の動線が変わるようなものです。
商売を続けていれば、これらは当然変わります。
問題は、何かを変えようとするたびに、柱や基礎まで壊さなければならない建物になっていないか、ということです。
システムも同じです。
- 商品を一つ増やしたいだけなのに、大規模な改修が必要になる
- 販売チャネルを増やしただけなのに、受注から請求まで作り直さなければならない
- 組織を変えただけなのに、あちこちのプログラムに手を入れなければならない
そうなっているとすれば、問題は個々の機能ではなく、その下にある構造かもしれません。
逆に、変えるところだけを変えられるのであれば、会社は経営判断を実行しやすくなります。
だから経営者がシステム投資で手に入れるべきものは、単に「今の業務を動かす完成品」ではありません。
会社を変え続けるための「構造」です。
ITの構造は、単なる技術上の問題ではありません。
会社が次に何をできるのか。その経営の自由度にも関わっています。
「構造を持つ」とは、未来を当てることではない
では、将来起こりそうな変化をすべて予測してシステムを作ればよいのでしょうか。
それも違います。
3年後にどんな商品を売っているか、どんな顧客と取引しているか、組織がどうなっているかを正確に予測できるはずがありません。
あらゆる変化に対応できる万能なシステムを作ろうとすれば、今度は複雑で高価なものになります。
大切なのは、未来を当てることではありません。
何を固定し、何を固定しないかを決めることです。
会社には、比較的変わりにくいものがあります。一方で、商品、価格、販売チャネル、組織、権限、承認ルールのように、経営判断によって変わるものもあります。
その違いを考えず、現在の業務をそのままシステムに焼き付けてしまえば、会社を変えるたびに大工事が必要になります。
逆に、変わる可能性があるものを最初から「変わるもの」として扱っておけば、会社の選択肢を残すことができます。
つまり「構造を持つ」とは、何でも変更できる万能なシステムを作ることではありません。
会社が変わったとき、変えるところだけを変えられる状態をつくること。
そして、
何を固定し、何を固定しないのかを、システムを作る前に考えておくこと。
この二つが重要です。
これは、IT部門だけの話ではない
何が変わる可能性があるのかを決めるのは、IT部門ではありません。
今後、モノ売りからサービスへ進むのか。直販だけでなく代理店やECを増やすのか。新しい料金体系を始めるのか。事業部制にするのか。M&Aをするのか。
これらは、経営の選択です。
もちろん、その選択をどのようなシステム構造で実現するかは専門家が考えます。
しかし、
「この会社では、何を変えられるようにしておきたいのか」
まで専門家任せにはできません。
経営者自身がデータベースやAPIの設計図を書く必要はありません。
その代わり、システム刷新を始めるときには、例えばこんな問いを社内や専門家に投げてみる。
- 「この会社で、3年後に変わっていそうなものは何だろう？」
- 「それが変わったとき、このシステムのどこを変えることになるのか？」
- 「その変更は、一部を変えれば済むのか。それとも大工事になるのか？」
商品かもしれない。売り方かもしれない。顧客との契約方法かもしれない。組織かもしれない。
この3つの問いに、システム設計の専門知識は必要ありません。
しかし、この問いがあるかないかで、システムづくりの出発点はかなり変わります。
その会社、コンクリートで固めますか？
システム化とは、ある意味で会社の仕事を固定することです。
曖昧だったルールを決め、データを定義し、処理手順を決める。固定するからこそ標準化でき、効率化できます。
だから、固定すること自体が悪いわけではありません。
問題は、何をコンクリートで固めたのかです。
顧客とはこういうもの。商品とはこういうもの。営業とはこういう仕事。この会社はこういう組織で動く。
その時点では、すべて正しい。
しかし商品は変わります。顧客も変わります。売り方も組織も変わります。場合によっては、会社の境界や商売そのものまで変わります。
会社が成長し、環境に適応し、新しいことを始めるなら、それはむしろ当然です。
だから経営者が手に入れるべきなのは、「今の会社にぴったり合った完成品」だけではありません。
会社を変え続けられる構造です。
内装は変えていい。売り場も変えていい。間取りだって変えていい。
しかし、それができるかどうかは、最初にどんな構造をつくったかで決まります。
3年後、「顧客」と「商品」は今と同じ意味でしょうか。
それは誰にも分かりません。
だからこそ、システム刷新で問うべきなのは、
「今の会社を、きれいにシステム化できていますか？」ではなく、
「会社が変わったとき、このシステムも変われますか？」
なのだと思います。
システムを作る前に、「何を変えられるようにするか」を整理しませんか
システム刷新や再構築を検討するとき、現在の業務や必要な機能を整理するだけでは、将来の事業変化まで見通すことはできません。
私たちは発注側の立場で、現在の業務を整理すると同時に、これから変わる可能性のある商品・顧客・販売チャネル・組織・業務ルールまで含めて、何を固定し、何を変えられる構造にするのかを整理します。
RFPを作る前、製品を選ぶ前、開発会社を決める前。
「何を作るか」が決まっていない段階からご相談いただけます。
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
