技術書籍の範疇に入るかどうかわからないのですが、信頼できるセールス・エンジニアになるには。と言うタイトルの本を読んでみました。
とある、大人から子供まで誰もが知っている、グローバルIT企業のHR (Human Resource=人事) の方に勧められたのでちらっと読んでみました。英語なのですが、平易な英語でスラスラと読めます。
著者は、後書きを見ると、「Oracle」「Sybase」「PeopleSoft」「Nortel」「CA Technologies」 や 「HP」 等で SE (Solution Engineer) 向けのトレーイングを行ったとされる 「Mastering Technical Sales LLC」 という会社の Managing Directorです。
こう言った研修は、ITの会社に居るとよく受けさせる事があるのですが、正直、ためになったか？と言われると・・・
ただ、たまにはしっかり読んでみようと言う事で、読んでみました。
目次毎に内容を追ってみる
しっかり読んでみようと思ったものの、内容が冗長な感じだったので、結局、読み飛ばしになりましたが、目にひっかかった所を一部だけ。
ちなみに、某社の方から、この本を紹介されたのが 2019年です。
Bottom Line up Front - What' In It For You?
著者は T/A プログラム (Trusted Advisor) の効果の例として、ある中堅のソフトウェア会社の例を挙げています。(T/A とは著者が作った略語と Section 1に解説があるので一般的な言葉ではないようです）
- RFP Reduction：Strategic Account のお客さんが書く RFP が半分に減った。RFPプロセスを省略する事ができるようになり、もっとバリューのあるセールスプロセスにフォーカスできるようになった（もっとバリューのあるセールスプロセス？）
- Increase In Deal Size：前年と比べて、ディールサイズが 19.5%成長した。新しいモジュールの追加も、価格の増加も無かったので著者が実施した T/Aプログラムのおかげである
Chapter 2 - How Do We Mesure Trsut?
- 事実を伝える事に慎重に。若いSEは時々、率直過ぎる事があります「それは決して上手く行きません」とクライアントに言う事はベストのアプローチでは無いかもしれません。
- 食べ物を使いなさい。朝食やランチや、お茶をしながらのミーティングは、親密さを作るのに良いです。
- スポーツや子供、趣味について話す事は、良いスタートです。
- 「わからない」と言いたがらない事はやめましょう。
- 反応するために聞く事を止めましょう。理解するために聞きましょう
- 知識や知恵、チップス、技術をあなたの同僚とシェアしない事を止めましょう。
Chapter 6 - A Little More About Trust
- 私のはじめの SEの仕事は、Mathematica でした。
- 私は、信頼が固定化されて、メンテナンスも無く維持できるようになった時が、一つのポイントだと思う。
Chapter 7 - A Little More About Advice And Advisors
- 全ては、聞いてもらえて、絶対的に指針にしてもらえるアドバイスを提供できる道を見つける事です。
Chapter 8 - The Built-In Advantage Of A Sales Engineer
- 信頼できるアドバイザーになる事とは、”アクセス”です。クライアントの建物へのアクセス、人へのアクセス。問題へのアクセス。問題が話合われているテーブルへのアクセス。お金を持っていて問題を解決出来る人へのアクセス。等など。
Chapter 17 - The Social Sales Engieer
- 接待は営業だけのものだと思わない。
- 私が最も好きなアプローチは、お客さんや見込み客に、「私はあなたの会社の近くに次の月曜日に行くんですよ」と声をかける事です。
- 同じ人に何度も合わない。
- お金はあなたが先に払うようにしましょう（現地や政府の習慣い従いましょう）
- 24時間以内にフォローアップをしてありがとうございました。と言いましょう。
Chapter 18 - The Listening Sales Engineer
- 判断を急がないでお客さんの話を最期まで聞く。結論がわかっていても、すぐに判断を下すと、スマートな人と言う印象では無く、傲慢な人に見える。
感想
要約すると「エンジニアでもお客さんと良いリレーションを作る事は大事だよ」という事でした。その為の方法として「理由がなくてもお客さん先に行こう」、「会社のお金で飲み食いさせましょう」等のこてこての手法が繰り返し紹介されています。
お客さんの担当者、決裁権を持っている人への「アクセス」が重要です。という主張は、確かにそこに尽きるな。と思いました。
この本は「Solution Engineer」と言いつつも、技術的なセンスをどう磨いていくかという事は取り上げられておらず「技術的に詳しく何でもその場で解決してしまうと傲慢に見える」等の、「見た目」の所にフォーカスした記述が幾つかありました。
全般的に、会社のバックオフィスの人でない限り、営業的なセンスは常に持っていないといけないものの、この本で書かれている対象は「Sales Engineer」というよりは、IT企業の「営業」はこうあるべきだ。と言う話である感じがしました。
私がこの本を紹介されたは 2019年ですが、著者が主に活動したのは、推察するに 2000年前半のようなので、当時はIT会社の営業も、技術営業も実態としては境界が無かったのかもしれません。
筆者がトレーニングを行ったとして例であげているPeopleSoft は 2005年にオラクルに買収されており、Nortel も 2011年に解体されて複数の会社に吸収されています。
ただ、実際会社が駄目になるかどうかは、ビジネスモデルの強さや、変化するビジネス環境に対応できるかどうかだと思うので、トレーニングが直接的なものではないでしょう。
また著者がSE時代の経験として引用している Methematica は、大学などの研究室でシュミレーションに使われるソフトウェアだったようです。
ただ、現在では単純に一つの製品だけを販売するようなITというのは、極めて少なく、ソリューションを組み合わせて、顧客の課題を解決していくケースもかなりあると思います。
ITの世界は様々で幅広いので、SE という職種の行動を単純にひとくくりにしてしまうのは、無理があるのだと思いました。
例えば私はシステムを設計する立場で基本的に案件は、RFPで公開され提案の内容で戦って行くのが主体でした。仕様の意図をきちんと聞くに相手と仲良くなる事はもちろん必用です。
一方で、筆者が何度も主張している食べ物等、金品を使って仲良くなり、情報を引き出す方法は論外ですし、情報を特別にもらう事自体も公正な競争が原則としてある大型案件では犯罪と見なされるものです。
この本では、顧客を直接会社の経費を使って飲み食いさせる事が「Solution Engineer」の前提となってたりする部分があり、現代では、よほど小さなスタートアップレベルでない限り「Solution Engineer」などの肩書きを持つ人がそのような権限を持っている事はないでしょう。
尚、ほとんどの国では、接待などは政府関係者に行っただけで「賄賂」となって犯罪になりますが、イギリスでは政府関係者以外でも犯罪になります。
著者がトレーニングしたとして事例に上げている会社はその後なくなっていたりという感じなので、やはり時代的にはIT界隈において「癒着型」メインの営業手法はメインの手法としては結果を出せないと言って良いのだと思いました。
ただ、販売するソリューションが単純でエンジニアリングの知識が必用の無い製品だったり、古い企業体質の顧客で、IT部門が随意契約できる決裁権を持っているような場合には、まだ効果があると思いました。