カテゴリー
デジタルトランスフォーメーション(DX)

SAP, Salesforceの導入

SAPやSalesforceをすでに導入されているお客様から、こんな声を聞くことは少なくありません。

  • アカウント月額費用が負担になっている
  • 使いにくい、日本の入力スタンダードと合っていない
  • ちょっとしたレイアウト修正やフィールドの追加が難しい
  • カスタマイズできても高額だ
  • 外部システムとの連携が難しい

特に本社が海外にある日本の会社の場合、本社(海外)の仕様に合わせてカスタマイズされているため、日本の入力になじまないことが多くあるようです。生産性を上げるためのツールであるはずがかえって生産性を落としているのです。一部のお客様は他のシステムや、専用のシステム開発に移行すするところも見受けられます。世界的なメジャーなシステムを使えば安心だという思い込みもあって導入を決めたのかもしれませんが、運用してみないことには業務にFitするかどうかはわからないことも多いのでしょう。システムに業務を合わせるのか、業務にシステムを合わせるのか、鶏と卵の関係に例えることができます。

業務にはそれぞれ特異性があり、生産性の向上には会社ごと、業務ごとに適したやり方があるはずです。世界標準と標榜しているお仕着せのシステムが示す業務フローが最適とは言えないのです。専用の業務システムの開発は業務分析を行いながら同時に運用の業務効率化も同時に検討します。トータルで最適化することこそが、もっともよいシステムと言えるでしょう。

カテゴリー
デジタルトランスフォーメーション(DX)

サブスクリプションビジネスの構築

サブスクリプションとは、定額制使い放題がその特徴であります。音楽や映画などのコンテンツはストリーミングによって配信される電子データそのものが主体であり、ユーザーの増減による影響は受けにくいものです。一方サービス系のサブスクリプションモデルは、提供されるものが料理であったり美容室などで受けるサービスであったり、供給する数に限度があります。多くは1か月あたりの利用限度数を設けているものが多いでしょう。有効期限が1か月の回数券を買ったことと同じことに気づきます。ハードウェアの機能を提供するものもあります。

ダイソンテクノロジープラス

月額1000円からダイソン製品を継続して試すことができます。1か月1000円でダイソンの掃除機能を使えると考えることができます。所有することからサービスを利用することにシフトするこのサブスクリプションビジネスはダイソン以外にもみられるようになりました。

契約するサービスレベルによっては万が一製品が故障してもサービス提供を維持する必要があるので、動作する製品と交換を行うこともあります。サービス(機能)を提供するため、交換する製品は新品とは限りません。故障品を修理し外装をクリーニングした整備品を用いることになります。このスキームを実現するには、不具合の申告から代替品の発送、故障品の改修、修理、整備、提供機材の補充を適切に行わなければなりません。運用設計とそれを実現する体制の構築が重要です。コールセンター、修理センター、物流センターは切り離すことが難しく、それぞれが連携することでサブスクビジネスを効率的に迅速に回すことが可能になります。またそれらをつなぐためのシステムも重要になります。

サブスクビジネスを企画、運営される事業者がこれらのセンターを構築するのは重荷になることでしょう。特にスタートアップ期ではなおさらです。サブスクの運用そのものはアウトソースしながら、事業の企画や営業にリソースを集中することが良いのではないでしょうか。

アウトソースのご相談を受けたまっています。

カテゴリー
デジタルトランスフォーメーション(DX)

システム開発コスト

Webシステムを発注したときにその費用は気になると思います。ソフトハウスも大手から中小様々ありますが、オフィスの立派さとコストはある程度の比例関係があると思ってよいでしょう。システムの規模によっても変化しますが、ある受付サイトを想定してみましょう。

  • 入力するのはお客様の住所情報
  • 入力した郵便番号から住所フィールドへ自動入力
  • 日時の予約。日付の選択はカレンダーUI。
  • 申込完了時のサンクスメールの送信
  • 申し込みデータはデータベースに登録

インフラは別です。ソフトウェア部分の開発のみです。このようなシステム開発を検討したときに数社に声をかけたところ、300万円~800万円の見積もりが出てきました。いかがでしょうか。思ってたよりも高いですか?開発に関わる工数によって変わるでしょう。要件定義をしっかりとやってから設計、実装と、工程ごとにドキュメントを整えながら行えばそれなりに人月(人件費)が必要です。大きなシステム開発会社であれば、開発は下請け、孫請けと委託して関わる人数が多くなりその分コスト高になることもあるでしょう。そうなると開発期間が3か月から6か月となり、その分コストが増えます。

コストを小さく開発することも可能です。ざっくりとした要件からプロトタイプを作って、レビュー、フィードバック、開発をスピーディーに回し、成果物は動く実体(システム)と定義することで、必要最低限の工程にのみコストを分配することができます。その分コストが安く済みます。仮に今回想定のシステムであれば要件を打ち合わせてプロトタイプまで1週間、レビューとフィードバックの1サイクルが1週間、仮にこれを3サイクル回すことで完成に至るとしたら、全体で約1か月でシステム開発が完了することになります。場合によってはコストを10分の1に圧縮できることもあります。

要件定義からしっかりと作りこむと、行き過ぎた考察から必要のない機能を盛り込む傾向があります。開発会社からすれば開発要素が増えることで売り上げが上がるので喜ばしいことかもしれません。プロトタイプから出発することは最小限の機能を実装して、それを触りながら必要な機能を洗い出していくのでかえって無駄がありません。追加機能はローンチした後に時期を見ながら追加していくことも可能です。せっかく作ったシステムが思ったほど利用されなくインフラ維持のコストが重くかかっている状況になったとしても、開発費が小さければ思い切ってクローズすることもできます。サンクコストが小さく出来るのもメリットと言えます。

システム開発の相談も承っています。

カテゴリー
製品評価

Amazonレビュー評価をよくする方法

製品の購入を判断するために、Amazonや価格コムなどのレビューを参考にすることが多いと思います。レビューで批判的なコメントが多い、または評価スコアの低い製品は敬遠しがちです。製品を販売する側は、どうしたらレビューコメントをよくできるか、評価のスコアをよくできるかが気になることでしょう。ここではさくらと呼ばれるレビューアーについては述べません。ここでは製品の品質に注目します。

レビューが相対的に悪くなるのは次のようなケースです。

  • 期待した機能、性能が製品に備わっていない
  • 生産国が中国だった
  • 使っているうちにすぐに壊れた
  • 取扱説明書が日本語じゃなかった。日本語の誤記がある
  • お客様の利用環境にマッチしていなかった
  • 新品のはずが、製品に汚れがあったり、梱包が破損していた
  • サポートに連絡が繋がらない

期待した機能、性能が製品に備わっていない
販売サイトやカタログに記載している製品の説明とそれを読んだユーザーの理解に乖離があるためかもしれません。記載に不足が無いか、誤解を与える記載になっていないか、ユーザーの目線に立って確認してみましょう。

生産国が中国だった
モノづくりにおいて中国は欠かせない存在になっています。中国製でない製品を見つけるのが大変にさえなっています。一般ユーザの中にはまだ中国製=品質が悪いと思い込んでいる節があります。日本国内で製造しながらいかにコストを下げられるか、その構造的に難易度が相当高いと思われます。中国製であっても満足できる品質のものを調達できるか、これが早期に対応できることだと思います。

使っているうちにすぐに壊れた
設計上の問題以外に、ユーザーの取り扱いに問題がある場合もあります。設計段階で想定していなかったユーザーのタフな扱い方、とくにモバイル製品では投げたり、落としたりは、精密機械という意識がないユーザーは平気で行います。調理家電では設計者が想像していなかった調理をすることもあります。切ったり混ぜたりする調理器具では想定した食材よりも固いものを入れたことで、回転する刃が欠けたり外れたりする事故が起こります。温める調理家電は想定した以外の調理を行ったことで、食材が詰まったり、燃えたりする事故が起こります。取扱説明書に書いてあったからと言ってユーザの利用方法を制限することは完全にはできません。機器に故障が起きれば、製品の不具合だとユーザは思い込みますし、メーカーに相応の対応を求めます。想定される利用方法を試すことで、実際に製品にどのような不具合が起きるのかどうかを確認しましょう。対策がとれるものは市場投入前に行っておくことでユーザーの不満を最小化できることでしょう。

取扱説明書が日本語じゃなかった。日本語の誤記がある
英語アレルギーのある方は少なくありません。取扱説明書が日本語じゃないだけでレビューのコメントに批判的な意見を残すケースも見受けられます。日本語で記載があっても、誤記や誤植があるだけで製品の品質に疑いの目が持たれます。技術的な表現方法もありますので、取扱説明書は単純に翻訳家による日本語化のほかに専門家のチェックを受けるのが良いでしょう。

お客様の利用環境にマッチしていなかった
特異なケースかもしれませんが一般向け調理家電を業務用途に使うユーザもあります。もともとの想定稼働時間が一般向けは業務用とよりもはるかに短く考えられていますので、耐久性よりもコストを優先して設計されています。業務用途で使う機材はそれなりの耐久性を持って作られている業務製品を使うべきだということは言うまでもありません。機器の故障により業務がストップする事態は避けなければなりません。

新品のはずが、製品に汚れがあったり、梱包が破損していた
レビューコメントでたまに見かけます。工場出荷時の検品体制が十分でなかったのかもしれません。検品体制が十分かどうか工場から受け取った時に受け入れ検査を行い、もしAQLを満足しない場合は工場にフィードバックすることも行います。

サポートに連絡が繋がらない
ユーザーからのサポートへの問い合わせはゼロにすることは難しいものです。製品の不具合以外に取り扱い方法の質問もサポートセンターの応対が必要です。サポートセンターに繋がらないことも製品のレビューコメントにいくつも見つかります。サポートセンターへの問い合わせが想定したよりも多くなっているのが原因です。オペレータの人数が不十分であるため、電話は鳴ってもそれを取ることができないのでしょう。そもそも製品の品質が良ければ、サポートセンターへの入電も多くなりません。当初想定したオペレータの人数で間に合うはずです。オペレーターの人数を増やすには、相当のコストが必要です。新規採用したオペレーターには教育が必要ですので、人数が集まればすぐに機能するかと言えばそう簡単ではありません。サポートセンターのコストを下げるにも製品の品質管理が重要なのですね。

レビューコメントでは製品に対する満足の声よりも製品やサポートに対する不満の声が大きくなりがちです。不満の声をいかに減らせるかは製品の品質が良いことが重要です。また不満の声からユーザーニーズをくみ取り、次の製品開発に活用できるかもポイントになります。

実用試験の提案
同様の既存製品から過去の事故事例を調査します。社内、社外の製品から幅広く調査しましょう。重大事故は製品事故情報・リコール情報でも調査しましょう。軽微な事故や不具合についてはレビューサイトのコメントを調査対象にすることもあります。製品カテゴリーごとにJIS規格が定められていますが、輸入製品においては規格の適合が十分でない場合もあります。製品企画・設計では想定していなかったエンドユーザーの使い方を幾通りも考えることもあります。これらの情報から試験対象の実用試験項目を作成します。試験の実施には人の手による長時間の繰り返し作業も必要になる場合があります。試験で検出した不具合は工場に改善の要求を出すことになります。不具合の度合いによっては市場導入にストップをかけることもあります。調理家電ではレシピブックに掲載されているメニュー全てを行ってみることも必要です。レシピ通りにやったのにうまく調理ができなかったというクレームをなくすためです。取扱説明書の内容の確認では誤記、誤植を見つける以外に、説明書通りの機能が実際製品に備わっているかどうかの確認も行います。説明書と製品の動作に差異があることもあった場合は、取説を修正するか、製品の動作プログラムを修正するかいずれかの判断が必要になります。

市場導入前の製品の、試験項目作成と試験実施を行っています。

カテゴリー
デジタルトランスフォーメーション(DX)

クラウドのメリット

社内システムをオンプレミス(自社設備で運用)からクラウドに移行を検討している企業様から相談を受けることがあります。今回はオンプレミスとクラウドの特徴を導入・運用目線で比較しました。

オンプレミスクラウド
イニシャルコスト100万円前後(構成次第)0円(従量課金の場合)
ランニングコスト電気代、保守時の費用3000円~(構成により)
立ち上げ日数30日(HWの納期次第、回線敷設、電気工事が必要になる場合もあり)数時間、単純なものは数分
保守ストレージやメモリーの故障に備えて自前でモニタリングや定期的な設備更新が必要クラウドサービスの提供者が設備更新を実施
設置スペース社内に用意する必要あり、セキュリティー対策、空調設備などのコストが必要サービス事業者が用意。セキュリティーの集中管理
廃棄廃棄費用が発生コストは発生しない。使った時間だけ課金される
拡張性HWの手配、回線敷設工事が必要、LTが必要必要な時に必要な期間だけ拡張することが可能。LTは数時間

オンプレのイニシャルが高額になっていますがHWは冗長化されている構成を前提としています。使用するパーツ、電源などもそこそこ品質の良いものを選んでおくことで、HW障害を極力回避できるはずです。クラウドはAWSやGCPなどの原価で想定しています。大手のクラウド構築ベンダーに依頼するとイニシャルコストで数十万以上かかる場合もあります。実際にそういった見積もりを目にしましたが、それらが使うクラウドサービスはAWSやニフクラといった誰でも直接契約可能なものでした。クラウドのランニングコストもサーバー監視やOSの保守も含めて数十万円がかかるベンダーもあります。ここでは他社に依存することなく自前で構築、運用することを前提としています。

オンプレ導入で見逃しがちなのが設置スペースです。ある程度の堅牢性をサーバーに求めるのでしたら、ブレードサーバーが良いでしょう。サーバーラックに何本も並べられますので拡張性も高いです。一方、設置場所の面積を必要とします。大きさは箪笥をイメージすると良いでしょう。かなりの重量物になりますので、床の補強が必要になる場合もあります。電源容量もそれなりに必要になります。電気工事が必要になることもあります。電気を消費すればそれだけ温度が上がります。温度をコントロールするためのエアコンが必要になります。サーバールームだと思っていただければ間違えありません。限りあるオフィススペースを有効的に活用するのにサーバーを自前で用意する必然性は今の時代ではほとんどないのではないでしょうか。

運用中は保守が必ず必要になります。保守費用の事を言うと必ず言われるのが「保守って必要なんですか」という言葉です。HWは必ずいつかは故障すると思ってよいでしょう。止まらないことが必須なシステムは、その「いつかは」に備える必要があります。2020年10月1日、東京証券取引所(東証)で相場情報の配信システムに障害が発生し、全銘柄の売買が終日停止になりました。原因はハードウェアの障害が発生したことと、バックアップへの切り替えがうまくいかなかったこととされています。相当なコストをかけたはずであろうシステムでもハードウェアの故障は起こり得て、リカバリーをおろそかにするとシステムダウンにより多くのユーザに迷惑をかけることになります。保守によって障害発生を未然に防止することを行います。システムの状態を監視することで障害を早期に見つけること、定期的にハードウェアを更新することで障害発生を防ぎます。オンプレで運用している場合は、保守の担当者をつける必要があります。専門的な知識が必要とされますので保守担当者のスキルは重要です。障害が発生してからHWの付け替えを行い、システムダウンタイムが1時間以上必要といった運用設計も見られます。壊れていない部品を定期的に更新するのはその分コストが発生しますので、経営的に判断が難しいところです。クラウドは保守コストも利用料に含まれていますので、ユーザが保守に関して頭を悩ますことはありません。クラウドサービスは利用期間が長くなればそれだけ費用がかさみ、オンプレよりも高額になるのではと心配されるかたもいらっしゃいますが、保守という観点から見れば決して高額ではないことがわかると思います。

クラウドベンダーに相談したけれど意外とコストが高かった、クラウドサーバーについてもっと詳しく知りたいといったご相談や、構築支援も対応しています。