新しい試みのトライアルとして、1週間分のサポート技術情報更新のインデックスを作成してみました。しばらく継続してみます。新規追加と内容更新したものが含まれています。システム上、軽微な修正であってもリストに含まれてしまいます。予めご了解ください。
Why Commerce (e-commerce) is not a Commodity の翻訳版です。
コマース (e コマース) がコモディティではない理由
2023年10月3日
著者: Gary Schoch / Global Digital Experience and Commerce Cloud Leader
さまざまなソフトウェア会社やコンサルタント会社から、「コマースはコモディティである」という意見がかなり前から出回っています。トレンドは「差別化を構築し、残りは買収する」ことであり、「構成可能なアーキテクチャが進むべき道」だと言われています。しかし、よりバランスのとれたアプローチを取るには、エンタープライズ規模が達成され、大きな価値を生み出している場所からの反対意見が必要です。
私の友人や信頼する人々は、過去数年間、莫大なマーケティング予算を使って業界でこれらのマントラを開発してきました。しかし、大規模なシステム インテグレーターやデジタル エージェンシーのプロバイダーとしての経験と、エンタープライズ ソフトウェア会社の従業員としての経験の両方を持つ私は、敬意を表してこれに反対します。
まず、「コモディティ」の定義は何でしょうか。ここで使用されている用語は、メリアム ウェブスターの定義である「大量生産された専門化されていない製品」であると想定します。
1 番目として、まず、拡張性とパフォーマンスを備えたソフトウェアソリューションを持つことは、コモディティではありません。カート(真のコマースプラットフォームでは注文としてモデル化されます)は「コモディティ」とは程遠いものです。注文を開発するための高いパフォーマンスを達成することは、収益を上げ、クライアントの競争に勝つために不可欠だからです。HCLSoftwareのトップB2Bクライアントの1社では、ページスピードタイムが10%向上すると、約9,000万ドル(約8%)の増分収益がもたらされることがわかりました。つまり、スピードは収益に等しく、重要です。
予想外のピーク時に注文量を処理することも重要です。すべての人のカートがコモディティであると言うのは正確ではありません。実際には、注文にはB2C、B2B、B2B2Cなど、さまざまな動作があります。HCL Commerce Cloudなどの同じプラットフォームでこれらすべての注文モデルをサポートすることは、コモディティではありません。
それを拡張することもコモディティではありません。それはむしろ、最初からプラットフォームの中核になければならない芸術形式です。なぜなら、そのスケールは設計に組み込まれており、後から追加することはできないからです。
これは、HCL Commerce Cloud クライアントのビジネス スケールの例です。
これは、複雑な価格設定、データ駆動型のパーソナライゼーション (特に CDP が高速 AI/ML 駆動型の洞察を推進し始めている場合)、複雑な価格設定モデル、プロモーション管理を行う企業にとって最も重要です。そして率直に言って、これらはオンライン収益の規模に関係なくほとんどの企業の目標であるため、すべての人に当てはまります。詳細が重要であるため、これはコモディティではありません。
2 番目に、ビジネス プロセス (顧客が構築およびパッケージ化) の動作を管理するために常に革新を続ける、一般的で使いやすいビジネス ツールを持つことは、コモディティではありません。顧客とのやり取りの速度をサポートする、粗粒度のパッケージ化されたビジネス機能 (Gartner の定義では「統合型コンポーザブル コマース」) の動作を自動化するために AI/ML の洞察を注入することは、コモディティのように思えるかもしれません。ただし、これを実行できるのは、初期設計で考慮に入れた堅牢なプラットフォーム プロバイダーだけです。HCLSoftware は、これを大きなチャンスであり、主要な投資分野であると考えています。
3 番目に、ソフトウェア ベンダーのサポートと説明責任は、特にオンライン収益の重要な瞬間には、コモディティではありません。HCL Commerce Cloud のクライアントの 1 社は、5 週間のピークを終えたばかりで、100% の稼働率で、問題は 1 つも発生していないことがわかりました。HCLSoftwareは、特にクライアントの大きなイベントでは、いつものように警戒を強めていましたが、すべてのクライアントに対しても同様です (クライアントのオンライン収益が年間 2,200 億ドルという素晴らしい評判がそれを物語っています)。
これは、通常は変化し進化している多くのベンダー コンポーネントを狭い範囲で集めたコレクションを組み立てる方が最適であると考える人々とは対照的です。
内部コンポーネントとマルチベンダー コンポーネントの両方を組み立てるというこの考え方を踏まえて、次の点を考慮してください。
セッション (リアルタイム) の重要な瞬間における単一の顧客ジャーニーは、多くのベンダー コンポーネントとクライアントが構築したコンポーネントを横断します。このような状況では、クライアントは自分ですべてを管理する必要があります。複数のコンポーネント ベンダーが電話でパフォーマンスの問題の原因を特定しようとするサポートの悪夢に陥ります。このシナリオでは、社内の顧客 IT 部門を除いて、誰も責任を負うことはありません。
「差別化を構築する」という言葉を聞くと、それは顧客にとっての「秘密のコード」です。彼らは結局構築モードに入り、ひどく不完全な「コンポーネントベースの製品」のセットを使用して、水平方向の顧客ジャーニーをサポートしようとします。問題は、複雑な価格設定からプロモーション、パーソナライズされたコンテンツまで、すべてに手を付けなければならないこと、そしてそれが迅速である必要があることです。
顧客に商品を提供することを約束するイメージを描こうとすると、顧客にとって大きなリスクが生じます。このリスクを押し付けるシステム インテグレーターはこれを、収益を請求したり大規模なサポート契約を獲得するための手段と見なし、結局は顧客に不利益をもたらすことになります。残念ながら、これは、カスタム ベンダー統合に関する知識がすべて従業員に渡ってしまう市場での人材不足と離職率を考えると、さらに深刻な問題です。
私のポイントは、アーキテクチャの純粋性に関する議論を完全に避けることです。市場の傾向はここ数年で急激に変化しました。 SOA、クライアント サーバー、N 層アーキテクチャ、さらにはヘッドレス (新しいものではありませんが、私は 1990 年代初頭からヘッドレス アプリケーションを実装しているので、それはまた別の機会にお話しします) が登場しては消えていきました。HCLSoftwareのクライアントは、顧客向けの新しいエンゲージメントを設計できる、スケーラブルで堅牢な高機能プラットフォームを求めています。また、イノベーションを推進するために、こうしたプロバイダーと提携したいと考えています。議論は「モノリス vs. コンポーザブル」ではなく、マーケティングの話題です。議論は、プライバシーとセキュリティを重ねたスピードとスケールでの収益成長です。
クライアントは、HCLSoftware のようなソフトウェア企業と提携することで、より多くのメリットを得られます。HCLSoftwareのソリューションは、スピード、スケール、セキュリティ、プライバシーという点で、新しい方法でオンライン収益を促進します。HCLSoftwareは、クライアントが直接価値を生み出す独自の新しいパートナーシップ契約を作成できるよう支援します。
HCLSoftware では、クライアントは #ExpectMore+ を実現できます。
これはソフトウェアの問題でも、テクノロジーの問題でも、アーキテクチャの問題でもありません。まずは設計の問題です。
これが、HCLSoftwareがクライアントのために #HCLCXStudio を作成した理由です。HCLSoftwareは、450 年を超えるデジタル エージェンシーの経験を持つチームです。HCLSoftwareは、1) HCLSoftwareのコマース プラットフォームがそれらのデザイン課題をどのように解決できるかを示すこと、2) 新しい機能のロードマップを知らせ、重要な差別化の領域についてクライアントに洞察を与えることを目的として、クライアントとデザイン課題に取り組みます。
この共同創造的アプローチは、クライアントが本当に価値を得られる場所です。#CXStudio の詳細については、こちらをご覧ください。
HCLSoftwareは、クライアントのために年間 2,200 億ドル以上のオンライン収益を生み出しています。HCLSoftwareが行っていることの芸術と科学は、「コモディティ」とはかけ離れています。HCL Commerce Cloud の詳細については、こちらをご覧ください。
過去数年間で、純粋なコンポーザビリティのコストは、大きなサービス料金、人件費の増加、およびリスクの増加を伴うことを学びました。代わりに、HCLSoftwareは、実績のあるスケーラブルなプラットフォームの「針の穴を通す」方法を見つけました。HCLSoftwareは、CX Studio アプローチを通じてクライアントと提携しながら、ビジネス プロセスの機能の深さの完全なセットを提供してきました。
朗報は、プラットフォームが死んでいないことです。まったくそうではありません。プラットフォームとは、実際には堅牢な機能の深さを意味します。最適なソリューションとは、拡張可能で、パフォーマンスが高く、安全で、プライベートであり、クライアントとベンダーのパートナーシップにより新しいイノベーションと IP を推進できる余地があるソリューションです。HCLSoftware が信頼され、説明責任を果たしている理由をご覧ください。実際に、それを証明します。これが、HCLSoftware が「信頼のプラットフォーム」と呼ばれる理由です。詳細はこちらをご覧ください。
HCL Commerce Cloud Scores 12 out of 12 Medals in the 2024 Paradigm B2B Combine Reports - again の翻訳版です。
HCL Commerce Cloudが2024年 Paradigm B2B Combineレポートで12個のメダルを獲得
2024年7月29日
著者: Brian Gillespie / Associate Vice President of HCL Commerce Cloud
B2B e コマース ビジネスと戦略の第一人者である Paradigm B2B が、昨年に引き続きHCL Commerce Cloud にメダルを授与しました。2024 年 Midmarket Combine レポートと 2024 年 Enterprise Combine レポートの両方で 、全12カテゴリで 12 個のメダルを授与したものです。今年は、これまでの業績を上回り、昨年よりも多くの金メダルを獲得しました。これは素晴らしい成果であり、B2B e コマースソリューションの卓越性に対するHCLSoftwareの一貫した取り組みを示しています。
レポートは、顧客やパートナーとの広範なインタビューを含む包括的な評価に基づいて 12 のカテゴリにわたってベンダーを評価し、顧客の真の声を反映しています。
今年の評価では、次のような素晴らしい結果を達成しました。
これらの包括的な評価は、ミッドマーケットおよびエンタープライズ B2B 企業の多様で複雑なニーズに対応し、最新の高性能なコマースエクスペリエンスを保証するHCLSoftwareの能力を強調しています。HCLSoftware の堅牢なソリューションは、その安定性、信頼性、拡張性が高く評価されており、顧客からは「高性能」で「すぐに使える完全な機能」と評されています。
ミッドマーケットレポートでは、Paradigm B2B は特に、複雑な商取引シナリオの管理とカスタム カタログの作成におけるHCLSoftwareの能力に注目しました。 エンタープライズレポートでは、HCLSoftwareの強力なプロモーション機能、成熟したバックエンドインターフェイス、ディーラー サイトとパンチアウトワークフローの効率的な管理が強調されました。
訳注: 「パンチアウト」とは、購買システムや経費精算システムなどに ログインし、そこから外部カタログサイトへ連携して選択した商品情報を元 に、申請や発注を行う機能のこと。
この評価は、卓越した価値とパフォーマンスをクライアントに提供することに尽力する、B2B 商取引ソリューションの大手プロバイダーとしてのHCLSoftwareの地位を強化するものです。
エンタープライズレポートとミッドマーケットレポートをこちらからダウンロードして、信頼性が高く高性能な商取引ソリューションを求めるミッドマーケットおよびエンタープライズ B2B 企業にとって HCL Commerce Cloud が最適な選択肢である理由をご自身でお確かめください。
Navigating Channel Conflict in Manufacturing with Digital B2B Commerce の翻訳版です。
製造業向けプレイブック:デジタルB2Bコマースでチャネル・コンフリクトを切り抜ける
2024年9月5日
著者: Karie Daudt / Director of Product Management at HCLSoftware
エンド カスタマーとの直接的なやり取りが求められる中、メーカーは重要な決断に直面しています。従来の販売チャネルを中断すべきか、それとも新しい市場の需要に適応できるようにするべきか。この変化は、特に現代の顧客の進化する期待に応えながら、ディストリビューターやディーラーとの強力な関係を維持するという微妙なバランスを管理する上で、機会と課題の両方をもたらします。
Industry Dive と提携して、「中断するか、可能にするか: 製造業におけるデジタル B2B コマースによるチャネル コンフリクトの管理」という包括的なプレイブックを作成しました。このプレイブックは、チャネル コンフリクトの複雑さをメーカーに案内し、収益と顧客満足度を最大化しながら、既存の販売チャネルを中断するか可能にするかについての戦略的な洞察を提供するように設計されています。
メーカーは長い間、販売の大部分をディストリビューター、ディーラー、卸売業者に依存してきました。しかし、デジタルコマースの台頭により状況は変わり、顧客は信頼するブランドとのより直接的なやり取りを求めるようになりました。このトレンドは、直接的な顧客関係から得られる貴重なデータによって推進されています。このデータは、メーカーが市場のニーズをより深く理解し、製品を改善し、競争で優位に立つために役立ちます。
しかし、これらのメリットには大きな課題が伴います。直接顧客 (D2C) モデルに移行すると、既存のチャネル関係が不安定になり、慎重に管理しなければならない潜在的な対立やリスクにつながる可能性があります。
当社のプレイブックでは、メーカーが採用できる 2 つの主要な戦略について検討しています。
このアプローチでは、従来の仲介業者を迂回して顧客と直接関わります。メリットは明らかです。データ収集の強化、市場の変化への対応力向上、ブランドと顧客体験に対するコントロールの強化、コスト削減の機会などです。ただし、チャネルのマインドシェアと売り上げの損失の可能性など、リスクも大きくなります。
販売チャネルに大きく依存しているメーカーにとって、破壊は最善の道ではない可能性があります。代わりに、デジタルコマースを統合し、チャネルパートナーをサポートすることでチャネルを有効化すると、バランスの取れたアプローチを提供できます。この戦略により、メーカーはチャネルパートナーとの強力な関係を維持しながら、貴重な顧客インサイトを獲得できます。このプレイブックでは、チャネルを有効にすることで関係を強化し、市場範囲を拡大し、共同意思決定を促進する方法について詳しく説明しています。
破壊するか有効にするかの決定は、軽々しく下すべきものではありません。慎重な計画、市場と顧客のニーズの徹底的な理解、強力な組織的連携が必要です。当社のプレイブックでは、メーカーがこの意思決定プロセスを進めるのに役立つ詳細なロードマップを提供しており、重要な質問、必要なリソース、ビジネスへの潜在的な影響などが含まれています。
当社は、メーカーが販売戦略をうまく移行できるようにするためのテクノロジーと専門知識を提供しています。AI と機械学習機能によって強化された当社の堅牢なデジタルコマースソリューションにより、組織はデータに基づく意思決定を行い、顧客とのやり取りを最適化できます。販売チャネルを破壊したい場合でも、有効にしたい場合でも、HCL Commerce Cloud はお客様独自のビジネスニーズをサポートするように設計されています。
プレイブックのダウンロード
チャネルコンフリクトの課題に取り組んでいるメーカーにとって、このプレイブックは非常に貴重なリソースです。情報に基づいた意思決定と持続可能な成長の促進に役立つ実用的な洞察と戦略を提供します。
お見逃しなく! 今すぐプレイブックをダウンロードして、デジタルコマース戦略の変革に向けた第一歩を踏み出しましょう。
新しい試みのトライアルとして、1週間分のサポート技術情報更新のインデックスを作成してみました。しばらく継続してみます。新規追加と内容更新したものが含まれています。システム上、軽微な修正であってもリストに含まれてしまいます。予めご了解ください。
2024年9月4日、HCLSoftware カスタマーサポートのドメインが、support.hcltechsw.com から hcl-software.com へ変更されました。当面はリダイレクトされるため従来のブックマークはそのまま利用できます。詳細は以下の記事を参照してください。
HCL BigFix on LinkedIn: Connect with Experts and Gain Insights の翻訳版です。
LinkedIn の HCL BigFix: エキスパートとつながり、洞察を得る
2024年9月4日
著者: Sana Nair / Product Marketing Manager
必要なのは、強力なツールだけではありません。HCL BigFixをご愛用いただいている皆様は、IT管理ソリューションの重要性をすでにご理解いただいています。そこで、HCL BigFix Enthusiasts LinkedInグループに参加することで、BigFixの経験を次のレベルへと引き上げることができます。
HCL BigFix Enthusiasts LinkedInグループのメンバーになると、他では手に入らない限定コンテンツにアクセスできます。
HCL BigFixの最新アップデート、新機能リリース、業界エキスパートによるベストプラクティスなどの情報を入手できます。HCL BigFixをより快適にご利用いただくためのウェビナー、イベント、特典情報をいち早くお届けします。
ネットワーキングはもちろん、プロフェッショナルとしての成長のための強力なツールです。LinkedInグループに参加すれば、同じ興味や課題を持つITプロフェッショナルとつながることができます。
ディスカッションに参加し、アイデアを交換し、共通の IT 管理問題の解決策を共同で検討しましょう。キャリアアップや組織の IT 運用の改善に役立つ人間関係を築くことができます。
解決策は同業者のアドバイスから得られることがあります。LinkedInグループは、ITエキスパートや経験豊富なHCL BigFixユーザーが知識を共有するためのハブです。
質問がある場合も、HCL BigFixのセットアップのガイダンスが必要な場合も、グループ内で豊富な情報とサポートを見つけることができます。
コミュニティに参加する最大のメリットの一つは、サポートを受けられることです。HCL BigFix Enthusiasts LinkedInグループは、あなたが助けを求め、他の人にサポートを提供できるスペースです。
あなたの経験を共有し、問題のトラブルシューティングを行い、一緒に成功を祝いましょう。この協力的な環境は、継続的な学習と改善を促進します。
IT業界は常に変化しており、業界のトレンドを常に把握することは重要です。LinkedInグループは、ITマネジメントとサイバーセキュリティの最新トレンドとイノベーションに関するディスカッションの場を提供しています。
業界のオピニオンリーダーから見識を深め、最先端の知識で一歩先を行きましょう。
HCL BigFix Enthusiasts LinkedIn グループへの参加は簡単で無料です!以下のステップに従ってください。
今すぐ参加して、HCL BigFix Enthusiastのメリットを享受しましょう。コミュニティへのご参加をお待ちしております!
Understanding Campaign Listener Clustering and Listener Failover - Part 2 の翻訳版です。
HCL Unica Campaign リスナーのクラスタリングとリスナーのフェイルオーバーについて - パート 2
Campaign にクラスター化されたリスナー設定が導入されたため、集中化されたエンティティからのリクエストが送信される複数の独立して動作するリスナーノードを持つ設定として考える必要があります。各リスナープロセスは、単一のリスナー環境の場合と同じように動作し (詳細については、このブログのパート 1 を参照してください)、マシンのローカルにある unica_acsvr プロセスを独立して起動およびシャットダウンし、独自の unica_aclsnr.udb ファイルを維持します。各リスナーノードは情報を共有しません。「マスターリスナー」が管理しているにもかかわらず、それらは個別の独立した単一のリスナーノードのように動作します。クラスター化された Campaign リスナー設定がどのようになるか、次の図に示します。
マスターリスナープロセスをロードバランサーとして考えます。 Campaign J2EE Web アプリケーションサーバーから Campaign にログインするか、フローチャートを表示/編集/実行する要求が届くと、Campaign Web アプリケーションは特定のリスナーと通信してこれを行うのではなく、クラスター化されたセットアップ内のマスターリスナーにそれらの要求を渡します。
次に、マスターリスナーは構成設定を確認して、どの子リスナーノードがこのタスクを実行するかを判断します。マスターリスナーがどの子リスナーノードが要求を受け取るかを決定すると、要求はその子リスナーノードに渡されます。
その時点で、その特定のマシン上の子リスナーノードは、非クラスター化されたセットアップで実行されている単一のリスナーノードであるかのように要求を処理します。適切な unica_acsvr プロセスが生成され、それらの unica_acsvr プロセスが要求されたアクションを実行します。次に、リスナーノードは unica_aclsnr.udb のローカル コピーを更新して、管理している unica_acsvr を認識します。
クラスター内の他の子リスナーは、他の子リスナーが何に取り組んでいるかを把握していません。すべてのアクティビティは、単一の子リスナーノードにローカライズされます。子リスナーノードは、管理している unica_aclsnr.udb ファイルから相対的なローカル unica_acsvr 情報を通信または共有することはありません。一部のユーザーリクエストが 1 つの子リスナーノードに送信され、他のユーザーリクエストが別の子リスナーノードに送信される場合があり、これらはすべて、環境の構成設定に基づいてワークロードを管理/バランスするためにマスターリスナーによってそれらの子リスナーノードに分散されます。
では、リスナーが使用できなくなり、フェイルオーバーが必要になった場合、これはどのように機能するのでしょうか。マスターリスナーが 2 つ以上の子リスナーノードを管理している場合、ビジネスユーザーから UI 経由で送信されるリクエストは、それらの子リスナーノード間で負荷分散されます。これらのリスナーノードの 1 つが手動介入またはその他のイベントによってダウンした場合、流入する新しいリクエストは、マスターリスナーによって、機能しているシステム内の残りの子ノードに転送されます。これらは別のマシンで動作しますが、同じシステムテーブルデータベース情報とファイル サーバー コンテンツ (共有ディレクトリ内) に引き続きアクセスできます。フロントエンドのビジネスユーザーにとって、ビジネスは通常どおりに進行し、ダウンタイムは発生しません。これは、他のリスナーノードがダウンしている場合でも、リクエストを受信できる稼働中のリスナーノードが少なくとも 1 つ残っているためです。IT チームは、フロントエンドのビジネスユーザーを混乱させることなく、舞台裏でダウンした子リスナーノードを調べることができます。マスターリスナーは、Campaign J2EE Web アプリケーションサーバーからのリクエストをリダイレクトする際に、スイッチを切り替えて、常に残りの稼働中のリスナーノードを指すようにします。ダウンしたリスナーノードが復旧すると、マスターリスナーは以前と同様に、そのノード (および他のノード) にリクエストを送信し始めます。
ここで、リスナーの 1 つがダウンし、そのリスナーでフローチャートとログインセッション unica_acsvr がすでに実行されているとします。その場合、何が起きるでしょうか。子リスナーノードの 1 つがダウンすると、マスターリスナーは新しいリクエストを他の子リスナーノードに転送しますが、リスナーノードがダウンしたマシンで以前から実行されていた unica_acsvr は、単一のリスナーセットアップのように動作します。フローチャートロジックはある程度まで実行し続けるかもしれませんが、そのマシンのリスナーがなくなるため、UI の更新やそれ以降の UI クリックは実行されない可能性があります。リスナーがダウンしても、unica_acsvr プロセスはリスナーノード間で転送されません。つまり、ノード A のリスナーがダウンすると、ダウン時に存在していた管理対象の unica_acsvr プロセスは他のリスナーノードで開始できなくなります。代わりに、フローチャートにアクセスするための新しい UI 要求を通じて、他のリスナーノードで再起動を手動で行う必要があります。
マスターリスナーノードが存在するマシンが使用できなくなった場合、Campaign は中断を回避するために、残りの子リスナーノードの 1 つを新しいマスターリスナーノードとして使用するように自動的に切り替えます。
要するに、クラスター化されたリスナー設定では、フェイルオーバーとは、リスナーノードがダウンまたはダウンしているときに、unica_acsvr プロセスの起動時に新しい要求が来た場合、常に実行中の子リスナーノードに転送されることを意味します。ダウンしたリスナーノードで実行されていた unica_acsvr プロセスは回復できません。ユーザーは、UI (フリーズしている可能性があります) からログアウトして、稼働中の子リスナーノードの 1 つで新しい Campaign ログインセッションを確立する必要があります。
ブログの最初の部分は、こちらで読むことができます - HCL Unica Campaign リスナーのクラスタリングとリスナーのフェイルオーバーについて - パート 1
クラスター リスナー設定の構成プロパティの詳細については、Unica ブログを購読して最新情報を入手してください。