知っているつもりだったが、実際の業務には細かい注意点があり、なるほど！と思うことが多々あった。
しかし、何故このような非効率な動きをしているのだろうかと思うこともあった。
想像しても仮説から脱することはないので、再度教えてもらうことにした。
自分たちも非効率であることは認識しているが、他の部署とのやりとりで決まったルールのようなので、従っているとのことだった。
古いシステム時代の使い勝手が悪かったことを運用で補っていた。また、ミスをしてお客様にご迷惑をおかけした経緯があり、再発防止のために非効率だが業務を追加していることもあった。 ]]>
よく話を聞くのは、売上や利益等です。確かに、売上が目標を達成しているか気になります。
では、目標を下回っていた場合、どのような対策をすればよいでしょうか？
お察しの通り、BIの結果が売上未達成の改善に役立つ情報が分析されてか？ という問いになります。
引き合いが減った、平均単価が下がった、ベテラン営業の受注単価が減った等々、様々な要因があります。
重要なのはKPIと構成要素であり、経営視点で検討しシステムに落とし込むことが大切です。
BIはデータの集計と思われがちですが、どのようなデータがあるかではなく、どのようなデータを取るかです。
ここで現場としては入力項目が増えて面倒になると言われ板挟みになります。
でも大丈夫。
実は会社の全システムを見渡すと、それなりにデータは集まります。
それでも残った要素は入力してもらいますが、あとはデータを集めることをすれば良いのです。
ERPの思想は、この延長上にあると考えてます。 ]]>
何故、このような考察したかといえば、ＥＣ販売の商品検討をしたとき、幾つか仕入れサイトに登録してみたが、コモディティ商品の販売となり、インターネットの世界では価格勝負になるので、大量仕入れをし、薄利多売となるのが基本的な考え方になる。当然、独自サービスを全面にして販売することは可能である。だが企業体力がある場合に限る。
ならばと、独自商品開発を検討したが、大量仕入をしない限り単価が割高となり、ブランドがないので、マーケティングコストも馬鹿にならない。在庫リスクを考え受注生産としても納期までの時間がかかり、販売戦略としては、好ましくない。
これでは八方塞がりなので、ビジネス構造を考察し、収益を圧迫する要素を除外できないか考えた。
Ｂ２Ｂのコンテンツビジネスの構造を考察してわかったことは、大きくビジネスモデルは２種類あった。
- 情報掲載料
- 手数料
情報掲載料は、広告と一緒で掲載しているコンテンツを見に来るユーザにリーチするためのものである。前提として、コンテンツの情報量が豊富で、精度が高いことが前提となるが、広告は継続して掲載する必要があるので、固定費がかかる。
手数料は、成功報酬であるものの数十％かかり安いわけではない。結局のところ、手数料分を契約金額に上乗せするので、割高になってしまう。
またまた、八方塞がりになってしまった。
よくよく考えると、ビジネス構造として買い手の方が強いと言われるが、小規模同士の売買は売り手の方が強いということがわかる。
ビジネス構造を改善するには直販に限る！
それだけでは不十分で、取引をする企業と信頼関係を築き、お互いに効率化を図りコストを下げることが出来なければならない。信頼関係はなかなか出来ないが、継続したビジネスをすることで、お互いを知り、実績が信頼を強める。
宣伝になるが、ZENEI（善栄）は直接取引の場を提供し、コミュニケーションが取れる仕組みを無料で提供するビジネスマッチング＋Ｂ２Ｂソーシャルコンテンツである。
経済を支える、中小企業・家族経営・個人事業主・フリー・副業のひとたちに是非利用してほしい。
一般的なものではなく実戦で！
相手が知りたいのは、事実の結論とリスク。
極論をいえば、他は全て補足資料の位置付けになる。
事実の結論は簡潔に述べる。他は事実を論理立てた説明である。
体制図は、誰がどの立場で担当するかで、その人の能力でリスク分析をする。
つまり、事実とリスクをうまく伝えられればよいのである。
何が言いたんだ！と言われたと耳にするが、結論を先に言わないこともあるかもしれないが、相手が理解できないのである。
だから、結論を言っても解決しない。今度はなぜ？と疑問に思うのである。
原因は、情報格差だと思う。
ITであれば技術かもしれない。本人にとって普通と相手にとって普通は違う。
同じIT業界の人でも話が通じないことは多々ある。
このような時は、情報格差を埋めることをすると良い。
例えば、トラブル報告の場合、
ルーターが壊れて大阪営業所がネットワークが、繋がらなくなりました。業務に支障があります。メーカーに至急交換品を手配してもらっています。
報告者は、ネットワークが繋がらないと、メール送受信、営業システム、スケジュール管理などが使えなくなることが暗黙的に知っています。
ですが、相手は影響はわかりません。なので、どんな影響があるのか知りたくなります。ようは、リスクを把握したいのです。
また技術者ならメールはキューに溜まっているので消えることはありません。しかし、相手からのメールは消えるのか？ さっき送ったメールは届くのか？ となります。情報格差ですね。
報告者は、ざっくりとした答えをもっています。決められないだけです。だから、許可を求めるようにした報告なら良さそうです。
事実とリスクを伝えれば、素早く相手は指示を出せます。そうすれば、報告ありがとう。修理頼むぞ！となるのです。 ]]>
ヒアリング結果をもとに、全体像を描くことにした。
D社小林「まずは、S社の全体業務の流れを記載してみてください。最初は詳細は不要です。全体的な観点で大丈夫です。いきなり詳細をまとめると、嫌になってきてしまいますからね。ホワイトボードに記載してみてください。」
佐々木「わかりました。こんな感じです。」
D社小林「山田さん。ここにシステムを記載してみてください。」
山田「わかりました。受発注システム、店舗システム、EC、顧客管理システム・・・。こんな感じです。」
D社小林「ありがとうございます。このシステム構成で問題になりそうなことは、何でしょうか？」
山田「データが分散されてしまうことだと思いますが、いまは定期バッチで連携していますので、問題ではないと思っています。」
佐々木「バッチで更新されているのは知っているが、翌日にならないと集計されないので、リアルで数字を知りたい場合があるので、都度、情報システム部に連絡をして集計してもらっている。」
山田「すべてをリアルにするには結構大変です。特にシステム毎に同じマスタでも管理項目が違うので、一緒にすることができない。」
D社小林「そうですね。でも、このプロジェクトでは、既存の考えを取り払って、あるべき姿をイメージしてみましょう。でなければ、現状からの脱出はできません。」
山田「ネットワークの見直しもある前提として、こんな感じかな。」
D社小林「すばらしいですね。ここに業務を意識して機能を置いていきましょう。」
佐々木、山田「全部ではないですが、できました。」
D社小林「山田さん。想定で良いのでデータベースを配置できますか？」
山田「ざっくりですが、こんな感じです。（黒線）」
D社小林「ありがとうございます。バイヤーとのヒアリングでもありましたが、在庫問題は機会損失にもなりますし、足を運んでいただいたお客様に申し訳ない気持ちになります。ですので、在庫など出来る限りリアルで基幹システムにAPI連携しましょう。（赤線）
もう一つ、せっかくのデータが集まるのですから、システム間の連携だけではなく、ERPの要素を取り入れて、ダッシュボードを作りましょう。各工程に携わる人たちが、事実を知り改善ポイントの情報提供です。
もちろん経営陣には、いま以上に経営に活用していただきます。」
連載 全社システム構想
佐々木「ダッシュボードには何が表示されるのでしょうか？」
山田「分析ツールを配るのは大変です。」
D社小林「ダッシュボードでいろいろと表示させたいですよね。でも、基本は財務数字の見せ方です。利益は売上から経費を引いた数字です。売上は各店舗の売上の合計です。ようは、あれもこれも表示しても利用者は使いきれないと思います。だから、押さえるべき基本を表示すればと思います。何を表示するかはノウハウです。」
佐々木「そういえば、渡辺COOも、いつもの決まったフォーマットの経営数字だけで把握されているようですし、それだけでなく的を得た課題をぶつけてきます。いつも不思議に思っていたのです。」
D社小林「深掘りするには分析ツールは必要ですが、日々の業務については、ダッシュボードでできるようにしたいですね。」
後日
佐々木「小林さん。ダッシュボードで何を表示するか腕の見せどころとありましたが、売上は当然知りたいですが、それでは目標に対する進捗はわかりますが、遅れていたらどうすればよいかわかりません。わかるようにするということですか？」
D社小林「その通りです。店舗によって要因は違うとおと思いますが、商品別、時間別などは共通して確認すべき要因です。そういった要因を表示してはと考えています。」
佐々木「ありがとうございます。考えてみます。」 ]]>
S社は、セレクトショップである。S社で取り扱う商品は、S社コンセプトを基準に他社も扱う商品もあれば、S社しか扱っていない商品もある。このコンセプトが、S社のオリジナリティになっている。流行りものは、お客様を呼び、定番商品が安定した利益になっている。常に全体最適化をしながら、商機を最大にする品揃えにするよう心がけている。
バイヤーA「売り方は、商品説明はするが、店舗に任せている。店舗では、商品毎に利益率が違うので、セット販売やキャンペーンなどの工夫をしているようであることは聞いている。同じブランドでも、限定モデルや、海外限定モデルを輸入することも検討している。バイヤーは流行りに敏感でなければダメで、加えてお客様の声を聞き、さらに一歩上の求める商品を探すことをしたい。」
バイヤーB「在庫が減ったら発注するが、バイヤーが担当している。商品を探しながら、発注業務をしているので、つらい。また、移動も多いので、お取り引き様から連絡がつかないと言われることが多々ある。」
バイヤーC「在庫が減ってきたら、各店舗から連絡がある。その後、こちらから各店舗に連絡をして売れ行きを確認して発注数を決めている。定番商品は良いが季節性がるような商品は発注数を間違えると不動在庫になってしまう。」
佐々木「発注数はどのように決めていますか？」
バイヤーC「よくはないかもしれないが、経験と勘です。ですが、いままで、大きく外したことはない。計算してくれたら良いが、いろいろな状況から発注数を決めているので、難しいと思う。」
佐々木「店舗によっても違うし、キャンペーン内容でも違ってくる。都度都度、考えることが必要なんですよね。理論通りにいかないから、人の能力が必要なんですね。」
D社小林「内勤バイヤーチームを作ってはどうでしょう。ある会社で採用されています。実際に取り引きしていたのですが、とても助かった経験があります。内勤者は、在庫管理、発注業務を担当し、お取り引き様と接点を維持する。バイヤーは、新規開拓とお取り引き様の関係維持と強化に努める役割です。」
バイヤーA「いいですね。効率よく仕事ができそうです。」
S社に限ったことではないが、バイヤーが商品を探し仕入数を交渉しているが、在庫数は仕入先の都合にも左右される。仕入先もビジネスであるため、S社が独占しているわけではないので、必ずしも満足する回答が得られるわけではない。
仕入先も直販、S社以外の納入先への配慮、生産キャパシティ、利益と様々な要素で判断して、バイヤーとの交渉に応じている。S社はセレクトショップであり、仕入先があって成り立っているビジネスであるので、仕入先を手厚くもてなすのが社風にある。そこで、情報戦略プロジェクトの構想として仕入先とも連携する仕組みとすることにした。受発注だけでは、S社の効率化が目的で入れていることになってしまう懸念があるため、様々な情報交換ができる仕組みへと発展させる。仕入先が大手であれば、自社システムである程度のことは実現できているが、中小零細企業であっても素晴らしい商品が多数あり、取引をしているが、システム投資をする予算はない。そこで、S社のSCM構想に、取引先が利用できるようにする。機能としては、お客様の声や、基本属性による販売数分析結果などである。これにより、お互いの信頼関係の強化と、仕入先の意思決定の材料になればと思っている。
もうひとつの課題である在庫についても、KPIによる在庫管理をして需要予測をして仕入先との生産計画に役立てるようにした。この背景には、仕入れまでのリードタイムが変動することがあり、話をしてみると、原材料が余らないように少なめにして、受注生産に近いことをしていると聞いたからである。これでは製造ラインのこともあり、都度都度の調整が発生し、お互いに良い関係にはなっていないと感じていたからである。
山田「具体的なイメージがつきません。」
D社小林「S社独自のEDIといえば、イメージできるでしょうか？ この機能を取引先に解放するのです。」
山田「わかったような、わからないような？」
D社小林「これから、全体をまとめるフェーズですので、そこで話をしましょう。」
オムニチャネルをテーマに議論することになったが「店舗とECの融合だろ！」「ネットで検索したら店舗に誘導するとあったぞ。」オムニチャネルについて議論が発散してしまった。
そこで、S社のオムニチャネルの定義を考えることにした。オムニチャネルもそうだが考え方であるので正解は無いが、S社としての考えがブレると効果が低いオムニチャネル施策になってしまうことを心配した。
オムニチャネルをどのように認識しているか、整理することにした。
- 店舗とECの融合
- 店舗への誘導
- 在庫を見つけ機会損失を減らす
の意見が多かった。
D社小林「ご意見ありがとうございます。まとめると、店舗とEC・インターネット・在庫がキーワードでした。各部門にヒアリングをした時もそうでしたが、店舗とEC は、共通して売上向上に個別に取り組んでいました。ですので、S社のオムニチャネルは「売上を最大にする」と定義しましょう。店舗でも、ECでも、お客様からすれば、どこで買っても同じです。在庫も機会損失を減らすためです。また、現在のように、個別に対応していては非効率でマーケティングコストが多く掛かってしまいますしね。」
山田・佐々木「皆さんも納得されているようですので、売上を最大する視点でオムニチャネルを考えましょう。」
D社小林「そのためには、S社サービスの統一が必要です。そのためには、店舗、EC で主張し合うのではなく、ベクトルを合わせて協力することが大切です。店舗の強みは強化し、弱いところはEC が補う。その逆で、ECの強みは強化し、ECの弱いところを店舗が補う。そうすることで、お互いに相乗効果が期待され、S社としてのオムニチャネルが実践できることになります。」
佐々木「でも、店舗もECも売上目標があります。たとえば、店舗がECを補った場合、売上は店舗になるのか、ECになるのかで問題になりそうです。」
D社小林「お客様からすれば関係ありませんが、目標制度がある限りは問題として取り上げるべき課題です。では、考えてみてください。いままででも、無意識に他店舗やEC に貢献していることは多々発生しています。在庫切れで、他店舗へ案内することもありますし、取り寄せもします。この場合、お客様が他店舗へ移動して購入したら、他店舗の売上です。在庫であれば、取り寄せをすることで、他店舗では機会損失リスクが高まります。ですが、皆さん協力して対応していますよね。ですから、課題ではあるものの大きな問題ではなく、気持ち的に不公平になることが不満であり、公平性を保てるような制度へと工夫をすることでクリアできるのではないでしょうか。それに、全社売上が達成しなければ、ダントツでトップの成績をだしたとしても、店舗は評価はされますが、ボーナスは原資がありませんので期待できません。どうせなら、がっちりと頑張った対価がもらえた方がよいですよね。」
佐々木「いわれてみれば、そうかもしれません。特に間接部門の評価は全社の成績で決まりますので、全社視点で目標達成に向けた動きをしていきたいです。この件は、課題として管理していきますが、評価に他店サポートポイントのようなものがあると良い感じもしますので、渡辺COOに相談してみます。」
3日後
渡辺「小林さん。佐々木から評価について相談があるとのことだが、知っていますか？」
D社小林「オムニチャネルの話ですね。店舗、ECを連携させると評価がどうなるか気にしていました。」
渡辺「給与に関係するからか。でも、小林さんとよく話しをしているが、数字だけで評価をすると会社は成長しない。それに間接部門は数字がないから評価軸が違う。会社は人で成り立っているので、部門に関係なくひとり一人の従業員が力を発揮できることが良い環境であると思います。評価は動機付けになるが、足を引っ張るようであれば意味がない。」
D社小林「その通りだと思います。渡辺さんは、大学院でも組織行動論には熱が入っていましたものね。」
渡辺「そうだったかな。佐々木の件は承知した。佐々木の勉強にもなるから、相談を聞いて宿題を出そうかな。」
山田は、ベンダー選定にあたり、田中部長から「プロジェクトはベンダーに任せて、ベンダー管理をすれば良い」と言われた。
しかし、山田には若かりし頃のベンダーにいた時の経験から、あの時のような仕事では、期待に応えられる結果が出せない不安になっていた。ベンダーにいた時は、納期に間にあわせるために連日の徹夜での突貫工事であった。やりきった感はあるが、お客様に期待した通りの開発ができたと思えなかったからである。要件定義を担当していた先輩に言われたことを設計・開発していたが、仕様変更が相次いだ。どうも、いろいろとお客様から指摘されていたようである。
振り返ってみると、お客様から言われたことを並べていただけの要件定義で、議事録と変わらず、ヒアリングの羅列でしかなかった。ビジネスは線であり広がりがあることを無視していたようである。
このような経験から、自分たちで納得するシステム化になるように、ベンダーには任せられないと思っていた。
改めて田中部長に相談してみたが「無理だ。ベンダーに任せろ！」と言われてしまった。
そこで、こっそりとコンサルタントの小林に相談してみた。
D社小林「田中部長の言われる背景には、皆さんには、通常業務があり、時間を割いてプロジェクトに参加している。情報システム部含めて全社員がプロジェクト以外の業務がある。だから、片手間ではプロジェクトを推進するのは厳しいので、ベンダーに任せることを指示していると思いますよ。しかしながら、山田さんの意見も理解します。失敗プロジェクトの多くは、山田さんの経験されたことと一致するからです。ベンダーは、コンサルティングをすると売り込むが、実際はシステムエンジニアが担当するので、コンサルティングというよりは、何を作るかヒアリングをまとめるだけである。ヒアリングが結果に矛盾があろうが、業務が非効率になろうが、疑問を感じない。全てのベンダーが、ダメというわけではなく、正直言えば、担当する人の当たり外れで決まるのが、現実です。」
プロジェクトにおけるベンダーの役割を考える
山田は、小林の話に納得しているもののベンダー選定をどうして良いか困っていた。
D社小林「山田さん。具体的にどうすれば良いか考察してみましょう。プロジェクトを成功させるには『人数ではなく、必要なスキルを持ったチームであることが重要です。』わかり易くいえば、プログラミングに強い人だけのチームでは、要件定義ができないので、プロジェクトは成功しませんよね。まずは、情報システム部の社員スキルを確認しましょう。」
- 田中部長は大手SI企業でプロジェクトマネジャー
- 山田も中堅のSI企業でプロジェクトマネジャー兼システムエンジニア
- 他の情報システム部部員は小さな開発会社で大手SI企業の下請けで設計と開発を担当
D社小林「情報システム部のメンバーの経験はわかりました。では、このプロジェクトを成功させるために何が不足しているか考えてみましょう。」
山田「小林さん。プロジェクトには、どのようなスキルが必要ですか？」
山田と小林で話し合った結果、上流含めた開発以外は、社員とコンサルタントを主軸とし、ベンダーには開発を主軸に期待することにした。
山田「PMOには、小林さんにも参画してほしいのですが、いいですか？」
D社小林「良いですよ。ただ、わたし一人では人数が足りないので、丁度わたしの会社に良い人財がいますので、参画させます。」
山田「でも、予算が・・・」
D社小林「開発ベンダーの予算から捻出してはどうでしょうか？ もともとベンダーに依頼する予定の上流工程の予算があるので、この費用を使えると思いますよ。」
山田「そうですね。同じお金を払うなら、適材な企業・人財に投資をした方が期待できます。」
D社小林「田中部長には、ベンダー丸投げにならないように注意するように、うまく伝えておきます。」
- プロジェクトマネジャーを補佐するPMO・ベンダーコントロールは、D社も参画
- 課題整理・ASIS、TOBEの可視化は、社員、プロジェクトメンバー、D社が担当
- 開発のための要件定義以降は、ベンダーが担当
ベンダーにはベンダーの価値がある。企業がベンダーに求めている価値とベンダーが得意とする領域がマッチしているとよいが、必ずしも成功するとは限らない。
情報システム部が、広域に渡るITスキルとビジネスとの親和性が高い設計をすることで、コストを抑えベストなシステムを作ることができる。理想かもしれないが、全従業員で稼いだお金は大切にしなければならず、無駄なコストは申し訳が立たない。できる限りでも理想を求めても良いかもしれない。悪い言い方をすれば、丸投げは失敗します。使うのは、皆さんであり、ベンダーではありませんからね。
アーキテクチャーは設計思想ですが、重要性に気が付いていない人が多いと感じています。
システムリニューアルする理由には、メンテナンス性が悪く何をするにもコストが高い。何かすると不具合が発生する。OSやミドルウェアのバージョンアップに対応するにはコストがかかる等々あると思いますが、実はアーキテクチャが大きく関係しています。
勝手な感覚値ですが、設計思想を持って設計する／しないでは、リリース後のメンテナンス性含めて、コストは、数十%の違いがでると思っています。
イメージして欲しいのですが、新築の家を建てる時に建築士が設計し、大工が建てます。アーキテクチャを甘く見ると言うことは、大工が設計書無しに経験だけで設計して建てることと同じです。違法しているかもしれませんし、窓の明るさが確保出来ないかもしれません。ようは、住む人の家ではなく、大工が立てやすい家になってしまう心配があります。
できてしまった後に、使い勝手悪いから直すとしても、ここに柱があるから動かせないとか、やるなら補強しないとダメとか想定外のコストと時間がかかってしまします。
そうならないように、将来の家族構成や趣味などを考慮して住む家を考えます。システムも一緒で、事業を考えて拡張性を持てる設計にする必要があります。