【連載】ヒアリングをまとめて全体像を描く

ヒアリング結果をまとめる ヒアリング結果をもとに、全体像を描くことにした。 D社小林「まずは、S社の全体業務の流れを記載してみてください。最初は詳細は不要です。全体的な観点で大丈夫です。いきなり詳細をまとめると、嫌になってきてしまいますからね。ホワイトボードに記載してみてください。」 佐々木「わかりました。こんな感じです。」 D社小林「山田さん。ここにシステムを記載してみてください。」 山田「わかりました。受発注システム、店舗システム、EC、顧客管理システム・・・。こんな感じです。」 D社小林「ありがとうございます。このシステム構成で問題になりそうなことは、何でしょうか?」 山田「データが分散されてしまうことだと思いますが、いまは定期バッチで連携していますので、問題ではないと思っています。」 佐々木「バッチで更

【連載】商品管理とバイヤー体制

バイヤーによる商品管理 S社は、セレクトショップである。S社で取り扱う商品は、S社コンセプトを基準に他社も扱う商品もあれば、S社しか扱っていない商品もある。このコンセプトが、S社のオリジナリティになっている。流行りものは、お客様を呼び、定番商品が安定した利益になっている。常に全体最適化をしながら、商機を最大にする品揃えにするよう心がけている。 バイヤーA「売り方は、商品説明はするが、店舗に任せている。店舗では、商品毎に利益率が違うので、セット販売やキャンペーンなどの工夫をしているようであることは聞いている。同じブランドでも、限定モデルや、海外限定モデルを輸入することも検討している。バイヤーは流行りに敏感でなければダメで、加えてお客様の声を聞き、さらに一歩上の求める商品を探すことをしたい。」 バイヤーB「在庫が減

【連載】SCM(サプライチェーンマネジメント)で仕入先との関係強化を図る

取引先との関係強化とSCM S社に限ったことではないが、バイヤーが商品を探し仕入数を交渉しているが、在庫数は仕入先の都合にも左右される。仕入先もビジネスであるため、S社が独占しているわけではないので、必ずしも満足する回答が得られるわけではない。 仕入先も直販、S社以外の納入先への配慮、生産キャパシティ、利益と様々な要素で判断して、バイヤーとの交渉に応じている。S社はセレクトショップであり、仕入先があって成り立っているビジネスであるので、仕入先を手厚くもてなすのが社風にある。そこで、情報戦略プロジェクトの構想として仕入先とも連携する仕組みとすることにした。受発注だけでは、S社の効率化が目的で入れていることになってしまう懸念があるため、様々な情報交換ができる仕組みへと発展させる。仕入先が大手であれば、自社システムで

【連載】自社のオムニチャネルを考える

S社のオムニチャネルを定義する オムニチャネルをテーマに議論することになったが「店舗とECの融合だろ!」「ネットで検索したら店舗に誘導するとあったぞ。」オムニチャネルについて議論が発散してしまった。 そこで、S社のオムニチャネルの定義を考えることにした。オムニチャネルもそうだが考え方であるので正解は無いが、S社としての考えがブレると効果が低いオムニチャネル施策になってしまうことを心配した。 オムニチャネルをどのように認識しているか、整理することにした。 店舗とECの融合 店舗への誘導 在庫を見つけ機会損失を減らす の意見が多かった。 D社小林「ご意見ありがとうございます。まとめると、店舗とEC・インターネット・在庫がキーワードでした。各部門にヒアリングをした時もそうでしたが、店舗とEC は、共通して売上向上に個

【連載】ベンダーには何を求めるか?

ベンダーには何を求めるか? 山田は、ベンダー選定にあたり、田中部長から「プロジェクトはベンダーに任せて、ベンダー管理をすれば良い」と言われた。 しかし、山田には若かりし頃のベンダーにいた時の経験から、あの時のような仕事では、期待に応えられる結果が出せない不安になっていた。ベンダーにいた時は、納期に間にあわせるために連日の徹夜での突貫工事であった。やりきった感はあるが、お客様に期待した通りの開発ができたと思えなかったからである。要件定義を担当していた先輩に言われたことを設計・開発していたが、仕様変更が相次いだ。どうも、いろいろとお客様から指摘されていたようである。 振り返ってみると、お客様から言われたことを並べていただけの要件定義で、議事録と変わらず、ヒアリングの羅列でしかなかった。ビジネスは線であり広がりがある

【連載】アーキテクチャを甘く見てはいけない!

アーキテクチャーを気にしないと失敗します アーキテクチャーは設計思想ですが、重要性に気が付いていない人が多いと感じています。 システムリニューアルする理由には、メンテナンス性が悪く何をするにもコストが高い。何かすると不具合が発生する。OSやミドルウェアのバージョンアップに対応するにはコストがかかる等々あると思いますが、実はアーキテクチャが大きく関係しています。 勝手な感覚値ですが、設計思想を持って設計する/しないでは、リリース後のメンテナンス性含めて、コストは、数十%の違いがでると思っています。 イメージして欲しいのですが、新築の家を建てる時に建築士が設計し、大工が建てます。アーキテクチャを甘く見ると言うことは、大工が設計書無しに経験だけで設計して建てることと同じです。違法しているかもしれませんし、窓の明るさが

【連載】店舗へのヒアリング

店舗へのヒアリング 山田たちは、旗艦店に出向きヒアリングすることにした。 店舗担当者からは、 店舗の営業成績がわからない。 売れ筋を感覚で管理している。 いまのシステムには、欲しい機能が追加されないので、東京店は独自で管理しているようだ。 全社キャンペーンが、店舗のキャンペーンを無視して企画されている。 在庫の奪い合い!売れる商品はECに持っていかれる。 在庫不足で予約を承るが、何度も来店いただくのが申し訳ない。 商品がマンネリ化している。似た商品になっているので、お客様の目をひく商品が欲しい。 アルバイトのシフトが大変である。 倉庫スペースが小さく、何を置き、何を置かないかわからず、悩んでいる。 と、いろいろな課題があることがわかった。また、店舗は、自分たちで企画し売上に貢献していることがわかった。 店員A「

【連載】ヒアリング失敗!理由は理解したつもり

設計失敗 ヒアリングをまとめて、要件定義書を作成してレビューをしたところ、指摘のサンドバック状態になってしまった。 指摘で多かったことは、利用する業務部門から「これでは業務がまわらない」と言われてしまった。 AS IS, To BE を作成し、レビューもした。業務の流れは理解したはずだった・・・。でも、結果は散々な状態である。 反省会 ベンダーは自社に戻り反省会をした。小林もベンダーから同席を求められ参加した。 反省会と言いながらも、最初は自分を正当化する愚痴である。 確かに言われた通りのことをつなげた。間違いは無いはずである。でも「業務を理解していない」と言われた。 小林が「業務を理解していないですね。というより、ビジネスを理解していないですね。S社は物を売る企業です。でも、ただ売るだけではないのです。販促を

【連載】進捗報告

気になることはそのままにしない ベンダーは、オンスケジュールの報告をしたがる。遅れていても、都合の良い過大解釈をして、オンスケジュールとして報告する。 報告を受ける側からすれば、安心するが、よくみて見ると、辻褄が合わないところがある場合がある。そのときは、説明を求めなければならない。本当にオンスケジュールではない可能性があるからである。 経験的に説明を求めた場合、ほぼ都合のよい解釈をしてオンスケジュールの報告をしていた。ベンダーも結局のところはバレることになり、進捗報告会の場で指摘をされ、事実の再報告を求められる。 また、リスケをして、リスケ後のスケジュールでオンスケジュールと報告をする。だが、違う。遅れには、変わらないのである。リスクを高めているだけである。このようなことをするのは、世界に1社だけかと思いきや

【連載】設計書レビュー

いままでのヒアリング結果を要件定義書としてまとめ、レビューすることになった。いつも、ベンダー視点のベンダーしかわからない表現で記載されていることが多く、しかし情報システム用語も多い傾向がある。D社小林から、要件定義書レビューについて、事前レクチャーがあった。また、情報システム部向けに、アーキテクチャの設計書レビューについて、説明があった。 要件定義書レビューはとても大切! 設計書レビューの仕方で、後工程の出戻り、品質、生産性は大きく変わってくる。しかし、やらなければならない業務は多数あり、期限に追われ、読み込む時間が足りないのが、実態である。そこで、押さえるべき本当のレビューポイントを理解することが、現実的である。 ヒアリングされた内容・用語が正しく理解されて記載されているか? ベンダーは、S社の業種経験者を担