企業の枠を超えた業務の仕方：パートナーや請負業者との連携

製品マーケティングの一員である、ダニエル・ルーが、拡張企業パートナー、つまり、「パートナー、契約社員、請負業者等と協業する働き方」についてご紹介します。

さらに、ディックススポーティンググッズ社での実際の運用についてもご紹介します。

まず「拡張企業」の定義について。使う人により意味合いが異なる言葉だと思います。そのため、まず、ここでは、拡張企業についてあまり深堀はしませんが、これに伴う課題について少しご説明します。拡張企業と業務を行う際の課題と、Oktaが課題に、どう対処するかを話します。その後、エドとエヴァに現場での実際についてお話を伺います。拡張企業の問題の対処を実際に聞けるのは興味深いですね。本当に楽しみです。

拡張企業とは

拡張企業とは何か。また、なぜこれが今日課題になるのか、ですが、従来は自社の従業員のみを憂慮していれば良く、この場合、ファイアウォールの背後で、企業が所有デバイスからアクセスしていました。しかし昨今、多くの企業が組織外からアクセスし、パートナー、請負業者、ユーザー等と業務をしています。企業は従来の枠組みを超えた多様な雇用形態の人と事業を進めています。そうしたユーザーは例えば、サプライヤー、ディストリビューター、リセラー、業務委託、派遣社員などです。この流れは、既に皆さんもご存じでしょう。従来の枠組みを超え、ともに働いている方もいますね。こうした人員は特徴があります。

第一に、彼らは一時的な存在です。少なくとも、従来の正社員より在職期間は短いのです

第二に、各々アイデンティティ（ID）を持ちます。しかし、社外からアクセスする各ユーザーのプロフィールや、ライフサイクルの管理、更新はほぼ行っていないでしょう。

第三に、彼らは御社のネットワーク外に存在し、新しいデバイスで新たな場所からアクセスします。こうした場合は、必ずしも御社の管理の範疇ではないのです。

そして最後に、しかも最も重要なことは、このようなユーザーに、選択的にアクセスが必要です。ファイアウォール背後やクラウドで保存済みリソースへのアクセスですから。

現在の状況は外部人員、つまり、会社が必ずしも管理はしていない人員が頻繁に出入りし、企業所有の機密情報へアクセスを得ようとする状況です。この状況には、いくつかの課題があります。きっと皆さんも拡張企業として感じている課題でしょう。
 

拡張企業の課題

拡張企業の課題は、約3点に絞られます。まず、統合の複雑さです。統合は、サードパーティーと企業の内部リソースを連携しますが、技術面だけでなく事業上の観点でも難しさがあります。新しい技術と古い技術が、常に共存できるわけではないからです。

次にITサポートの増加です。オフボーディングやオンボーディング、そして自社従業員へのITサポートの提供等が、すでにIT部門の作業負荷でしょう。加えてパートナー、請負業者等外部ユーザーも加わるので、「ITサポート」がさらに複雑になります。

そして最後に、セキュリティリスクです。新しいユーザーが新しい場所から来たり、新しいユースケースなど、新しセキュリティリスクが生じます。ここは熟考の必要があります。

これらの課題は、上位概念としてラフに問題を捉えていますが、若干抽象的です。Oktaのお客様との対話からの学びは、お客様の直面する課題は5つに集約できるということ。

• まず、「パートナーのIDソースに接続する方法とは何か？」

• 2つ目は、「安全かつ選択的アクセスを提供する方法は？」

• 3つ目は、ユーザーの出入り時、権限の自動付与の方法は？

• 4つ目は、的確な適合性をどう検証するか？

• 最後は、外部ユーザーのオフロードをどう管理するか？

この5つについて考えていきます。

Oktaがお客様からよく聞かれるのは、アクセスを要する真のIDをどう接続するのか、です。自社ユーザーであれば、ものごとは簡単です。簡単ではないにしてもなんとか解決できる。自社所有するディレクトリにあるユーザーで、ディレクトリはおそらく、Active DirectoryやLDAPなどでしょう。そのため、ユーザープロファイルw管理更新する責任は自社にあり、滞りなく行われていたと。しかしここにきて、こうしたパートナーと働く機会がますます増加し、管理が複雑になってきた、というわけですよね？

パートナーのユーザーを自社のActive Directoryに加えたくない、外部のパートナーユーザーのプロファイルやライフサイクルを管理、更新する責任を自分が負うのも嫌でしょう。

また、CSVファイルをあなたとパートナーの間で、行ったり来たりさせるのも避けたいと。当社のお客様の一部は、実際そうしていますが、これでやり続けるのは正直きびしく、安全でもありません。そのため、パートナーのIDソースに接続する方法として、Oktaは3つの異なる方法をお奨めしています。

ディレクトリの統合

1つ目が、ディレクトリの統合。これはこのとおりで、皆さんがすぐできる方法です。当社では、軽量のADやLDAPのエージェントをインストールし、御社のActive DirectoryまたはLDAPディレクトリに、このプロファイルと御社のOkta Orgを同期します。

我々は御社のパートナー企業でも同じことができます。同じ軽量エージェントを彼らのAD、またはLDAPドメインにインストールします。この場合、皆さんがパートナーの環境に何かインストールしなければならず、御社とパートナー間でこれができないこともあるでしょう。

アイデンティティフェデレーション

次のアプローチは、アイデンティティフェデレーションです。特にパートナーが大企業の場合、既にIDソリューションを使用中という事があります。Oktaは、SAML認証によるIdP全てに接続可能です。Microsoft ADFS、CA、Pingなど、その他御社のパートナーが使用するサードパーティIdPに接続可能です。シームレスに接続できるため、御社のパートナーが自社で使用中のIdP、つまり、アイデンティティソリューションに接続が可能です。エンドユーザーの体験は全く阻害しません。

「ハブとスポーク」方式

そして最後に、「ハブとスポーク」方式です。この方法は、IDソリューションを持っていないパートナーに最適です。これがコンセプト図で、御社のOkta Orgを御社パートナー管理のOkta Orgに接続するのです。Okta事態、SAML認証のIdPで、OktaはいなかるSAML認証のIdPに接続可能です。別のOkta Orgにも簡単に、シームレスに接続可能です。これが御社パートナーがIdPを持つための最善の方法です。パートナー自体が自社ユーザーを管理でき、パートナー自社内のアプリ管理も自社内で行うことができ、一方、御社がパートナーのsub orgに接続することも可能です。ハブは御社のOkta Orgとなり、スポークはここにあるSub－Org組織です。

この3つのアプローチでアイデンティティソースに接続が可能です。

IDへのアクセス付与

次にお客様から、「そうですね。IDソースには接続したものの、このようなIDにアクセスを与えるにはどうすればいいか？」と聞かれるのが常です。ここでの課題は、御社のパートナーや請負業者は、御社の規制外の場所やデバイスからアクセスするので、可視性がないのが問題です。

ユーザーは御社が所有するリソースへのアクセスが必要ですが、選択的なアクセスでなければならず、御社の全情報にアクセス提供する必要はありません。そのため、VPNなど厳格なやり方は、優れたソリューションとは言えません。また、このソリューションは御社のパートナーや請負業者が簡単に使用、処理できなければなりません。面倒すぎたり複雑だったりする新しい技術に、パートナーを埋没させ混乱させたくないはずです。

では、どんなソリューションが提供できるでしょうか？皆さんがシンプルなツールOkta SSLソリューションを試用されていることと望みますが、これは、御社のユーザーが必要なツールやリソースにアクセス提供するものです。御社の従業員にはよく使われる方法ですが、パートナー、請負業者、派遣社員等にも優れたソリューションです。どんなデバイスからでも、御社のネットワーク内外からでも問題ありません。

OktaのMFA

このアクセス方法に加え、OktaはMFAで安全性の向上を推奨します。これは非常に便利です。ユーザーを保護するだけでなく、それ以上に、御社のパートナーや請負業者にも非常に重要です。御社はこのようなユーザーを管理せず、セキュリティ慣行も知らず、彼らがどう管理されているか、どこから来ているか知らない。その場合、アクセス方法に加え、MFAの利用が極めて重要です。

ユーザーコンテキストの紐づけ

Oktaでは、さらにアクセスにユーザーコンテキストを紐づけます。アクセスに使用する情報は、ユーザー名とパスワードのみならず、ユーザーの行動や発信元に関するコンテキストなどの情報を用い、アクセス許可を決定します。例えば、どのアプリへのアクセスを得ようとしているのか、どのユーザー属性ルールが適用されたか、ネットワーキングコンテキストのIPアドレス範囲は既知で信頼できるか、デバイスは何か。みなさん、パートナーはデバイスから来ます。BYODにおける課題は、従業員のデバイスを管理もせず、見ることもないということ。この状況でいかに決定を下すか、です。

ロケーション情報の利用

そして場所の情報です。国、都市、郵便番号等、ユーザーのアクセス元の情報を用い、より多くの情報を得て、アクセス許可の決定を下します。Oktaはこれらすべてをリスクとみなし、評価後、コンテキストに基づき応答します。ここで、その人物のその先のアクセス拒否をしますが、より頻繁に行うのは、一種のMFAプロンプトの仕様です。Okta Verifyプッシュ等です。

ITが良く聞かれる3番目の質問は、ユーザー出入り時に、ユーザー権限をどう自動付与するのか？です。これは特に、派遣社員や請負業者の対応で重要です。なぜなら彼らは短期的な存在だからです。ITは彼らの着任初日に、必要なリソースへのアクセス提供がでいているか確認の必要がある、と。一方で、このような人員が離職する、または、異動する初日には、オフボーディングプロセス中、即座にプロビジョニングの解除が必要です。アクセスすべきでないリソースにアクセス不可とするためです。これが問題になりえます。こうしたユーザーは従業員より着任・離職が頻繁で、また一年のある時期に急増することもありえます。これについては、ディックススポーティンググッズ社から、特定の時間のみの季節雇用者をどう扱っているのか、事例を伺います。

また、多数のユーザーのオンボード／オフボードを一度に処理するのは、IT部門の過度な負担になる可能性があります。全オンボードと全オフボードを手動で行うのは、ITリソースを消耗させ、かつ、セキュリティリスクでもあります。このような多くの主導のアクティビティは、エラーを引き起こします。人的エラーです。ボタンを間違えて押すかもしれません。Oktaのライフサイクル管理は、この問題の解消を意図しています。ユーザーの情報をソースから取り込んで、それらの情報を使い適切なリソースを割り当てます。

また、権限の監査やレビューツールもあり、ユーザーが確実に適切なリソースへのアクセスを継続的に利用できるよう確認でき、必要な場合には、即座にその人たちをオフボーディングすることが可能です。この全てを一元化したポリシーにて行います。そのため、ITは各ユーザーに手動で実行する必要はなく、就業や離職のたび操作せずに済みます。

Automations

我々は開発を継続し、機能を改良する新機能を追加しました。ライフサイクル製品を改良し、自動化がさらに進みました。Oktaはこの新機能のご紹介を喜ばしく思っています。Automationsという機能です。新しくリリースされた機能で、現在はEA（Early Accees）です。もし興味があればご覧ください。

Automationsで、Okta管理者は主導タスクを自動化することが可能です。例えばOkta管理者は、「条件」と「アクション」からなる「自動化」を設定できます。その後Oktaは、記載された「自動化」条件を評価し、特定のアクションを実行すべきかを決定します。つまり、豪華なif-then構文なのです。「ifこれが起きたら、then私たちはあれを実行する」と。事例でよりリアルに考えてみましょう。

例えば、特定の日に複数の請負業者を一括停止するとします。その理由は、彼らの契約終了日が年度末であるためです。また、この左側には管理者が設定した条件があります。右側はアクションです。この条件が適合したら、アクションが実行されます。そしてグループがあり、請負業者がある、と。この請負業者のグループ全てが該当します。この条件は、年度末に一回事項されます。請負業者をオフボーディングする必要があるタイミングだからです。その後、そのタイミングが来たらこの請負業者のグループを停止します。ユーザーの終了時がわかれば、優れたユースケースです。

わからない場合どうするか、ですが、より高度な設定が必要です。できることは、非アクティブ状態に基づき停止することです。つまり、年末に一回という規定時の実行だけでなく、例えば毎日、1日の業務終了時に、この自動化スクリプトを実行することも可能です。「ユーザーが30日間ログインしない場合、そのユーザーを停止する」過去30日間にそのユーザーがログインした場合は、問題なく、継続してアクセスを利用できます。これは変更できます。「7日間、もしくは、一定期間保留でアカウントを停止する」などです。他の理由もあるかもしれません。

一例は、「IT部門がアカウントを作成したが一度もそれが有効化されない」というものや、「長期間保留である」などです。このようなアカウントを長期間、保留状態で放置しておかず、まず一旦停止し、さらに調査し「このユーザー」は確かにアクセスが必要であるかを確認できます。または「当該ユーザーは既にアクセスは不要だ」と自動で判断します。これがAutomationsです。これは非常に強力な武器です。ここで挙げた使い方はほんの一例です。昨日開発は継続中で、今後も多くの機能追加をする予定です。Automationsは非常に強力なツールです。ぜひ皆さんにも今後、活用いただきたいと思います。

次の質問は、コンプライアンスに関してです。「パートナーや請負業者、派遣社員が常に出入りしている環境で、全ての人が適切なレベルのアクセスを持っていると確認する方法は？」「放置されたままのアカウントがないことを監査の際にどのように証明できますか」と。Oktaにはたくさんのレポートがあり、Oktaの管理者が環境内で何が起きているかを把握するのに役立ちます。また、コンプライアンスの問題を証明する場合にも役立ちます。全ては難しいのですが、一部をご紹介します。Oktaには多くのレポートがあり、お役に立てると思います。皆様にとって馴染み深いSyslogも同様に便利ですが、ここでは3つだけご紹介します。

割当レポート

1つ目が現在の割当レポートです。これは特定期間内のアプリケーションの利用状況のデータです。このレポートでは、特定のアプリにどのユーザーが割り当てられているのかわかります。また、特定のユーザーに関して、そのユーザーに割り当てられているアプリは何かが分かります。これで、御社の組織内で起きていることがよく理解できます。

アクティビティレポート

2つ目が不審なアクティビティレポートです。その名のとおり、怪しいアクティビティを見つけ出すためのレポートです。特定期間内で組織内で発生している事象をレポートします。不審なアクティビティの一例としては、多くのパスワードリセットを受信しているとか、パスワードロックアウトが発生している、等です。つまり、不審なアクティビティレポートを参照して、組織内における異常な事象の有無を理解するのに役立ちます。

不正アカウントレポート

そして最後に不正アカウントレポート。これはOkta内の割当を比較し、Oktaに接続しているアプリケーションの実際の割当を比較します。おそらく、御社内にアプリの管理者がいて、手動でOktaの外にあるアプリケーションにユーザーを追加している。このレポートがするのは、この2つを比較して不正アカウントがないか、Oktaと実際のアプリケーションの間に不一致がないことを確認します。最終的には、御社は全ての割当をOktaを通して行いたくなるでしょう。

最後に、IT部門にパートナーユーザーからの対応で多忙になるのは避けたいはずです。Oktaには複数のセルフサービス機能があり、小さなアカウントの問題の管理を支援し、御社のユーザーやパートナーや請負業者が、ITヘルプデスクに問題解決のために連絡してくることはなくなります。

皆さんは、パスワードリセットのワークフローはよくご存じでしょう。当社には、セルフサービスパスワードリセットフローや、セルフサービスアカウントロックアウトフロー、セルフサービスMFAなど多くのセルフサービスツールがあります。ユーザー管理の負荷を軽減するためのサービスです。こうした基本的なITタスクをヘルプデスクから解放し、ユーザー自身が対応可能となります。では、ユーザー管理はどうでしょう。管理者タスクをパートナーも含め別の人員に委譲したいと思う場合も、完全な管理者権限の他のユーザーに付与したいとは思わないでしょう。ではその場合には何ができるでしょう。

Oktaは、多くの「事前定義済みの管理者ロール」があります。ご参加の皆様は、もうOktaのスーパー管理者についてはご存じでしょう。スーパー管理者のみならず、複数の異なる管理者ロールも作成しました。そのロールは特権が少なく、特定のユースケース向けに設定しています。例えば、ヘルプデスク管理者がこのずっと右のほうにいます。この人たちは私たちを助けてくれます。管理者だけがアカウントのアンロックや、パスワードのリセットができますが、彼ができるのはそれだけです。ヘルプデスクIT部門の仕事をサードパーティの請負業者に委託する場合、威力を発揮します。

そして、お客様からの声でいただくのは、「どのような種類のロールが重要か、便利か」というものもあります。そのため、先日の新しいロールレポート管理者ロールを追加しました。この役割は、レポートの一部を生成することができます。監査用等です。それ以上はできません。制限した権限で特定のユースケースを目的とします。しかし、お客様にはこれ以外多数のユースケースがあると。この9つの事前定義したロール以上必要だと理解しましたので、お客様にはより多くご提供する方法の検討に着手しました。柔軟に社内で独自のロール設定を可能とする方法です。

近日中に発生する予定なのが、カスタム管理者ロールです。管理者が特定のユースケースのロール作成を可能とします。Oktaの事前定義したいロールを試用せずに済むようになります。このロールは、数が決先に発表予定です。このような機能はOkta管理者の業務を楽にし、パートナーや請負業者、派遣社員の管理もより楽になります。ここまでが、お客様から拡張企業についてよく聞かれる５つの質問への答えです。

どのようなアプローチでパートナーのIDストアに接続するかということ。SSOおよび、MFAがセキュリティレベルの向上に役立つこと。特に制限が難しく可視性が低いうユーザーに役立ちます。また、当社の新機能Automationsについて。ユーザーの出入り時のユーザー権限の自動付与が可能です。当社の便利なレポートをぜひお使いください。必ず役に立つ機能です。また、どういった方法でパートナーユーザーの負担を対応可能な他の人員に譲渡し、皆さんが本来やるべき業務に集中が可能となることもお話しました。

つまり、本日のポイントは「拡張企業は優先事項」ということです。いくつかの問題はありますが、Oktaは複数の選択肢を提供し、従来の枠組みとは異なる仕組みでユーザーを保護し、アクセスを付与し、御社事業のさらなる前進に貢献します。是非、今後もOktaをご検討ください。

ディックススポーティンググッズ社の事例

ここからは、ディックススポーティンググッズ社のITプロジェクトマネージャー/エンジニアリングマネージャーであるエド・ハイザーと、カスタマーインタラクションのITプロダクトマネージャーであるエヴァ・シューリにお話を伺います。

エドは過去6年間、ディックススポーティンググッズ社のeコマース担当で、オムニチャネル、カスタマーフルフィルメント、カスタマーサービステクノロジー等に携わってきました。

エド・ハイザー：

良いビジネスには必ず、クールな創立当時の逸話があるものですよね。入ったばかりの新人選手を見て、誰もが「あいつはプロにはなれないさ」と思っていた。それが私たちの会社、ディックススポーティンググッズです。ディック・スタックと彼の兄弟の最初の「釣り餌と用具」点は、ニューヨークのビンガムトンにありました。1948年のことです。

当時ディックは、軍の余剰品を売る店で働いていました。ある日オーナーが来て、「ディック、釣具店をやるのに何が必要だと思う？」と言いました。ディックは家に帰ってからその宿題に取り掛かり、後日オーナーに提案書を提出したわけです。オーナーはディックを見て咳払いをし、こう言いました「バカ、お前はバカだな。何もわかっていない」。

その後、ディックはその提案書をもって家族の元に行き、「自分にはこれができる」と言うと、彼の祖母が、彼女が生涯かけて貯めたお金をクッキー缶から取り出してディックに渡しました。これがディックススポーティンググッズの始まりです。

現在、当社はディックの息子・エドが経営者で、彼は当社の現CEO兼会長です。当社は700店舗以上を展開し、オムニチャネルでスポーツ用品小売店を展開、市場のリーダーです。当社はField and Stream、Golf Galaxy、Team Sports HQ等を扱っています。

エヴァ・シューリ：

私の業務は、当社のカスタマーサービステクノロジーに付加価値を与えることです。カスタマーサービスの注文番号対応から始まり、トラブル対応、アンケート等を担当しています。もし、これまで私の部署とやり取りをしたことがある方がいらっしゃったらごめんなさい。ディックススポーティンググッズと当社の歴史はすでにエドがご紹介したとおりですが、私からは、より直近の当社の歴史を少しご紹介します。

数年前から、当社はeコマース関連事業を内製化し始めました。カスタマーサービスセンターの内製化もこの一つです。当社の店舗同様に、eコマースのフットプリントもカスタマーサービスも成長しました。当初は数十人のエージェントが古い事務所で働いていただけでした。それが今は、複雑なカスタマーサポートサービス組織に成長しました。今はノンホリデー顧客エンゲージメントセンターに関し、実在する3か所とバーチャルの1サイトでビジネスパートナー2社を活用して運営しています。

このセンターが顧客エンゲージメントやカスタマーサービスのニーズに対応します。このセンターは3つのチェーン店も対応します。Golf Galaxy、Field and Stream、Dick’s Sporting Goodsです。3チェーン店のeコマースウェブサイト、実店舗も対応します。また、当社のスコアカードロイヤルティプログラムも対応します。しかしこれは、平常運用時の話です。

スポーツ同様に小売り業にもシーズンがあります。小売り業にとっては、ホリデーシーズンが一番大事です。繁忙期には、通常の3倍の人員を補充し、顧客ニーズに対応します。この拡大により、実サイトが3か所から7か所に増え、仮想サイトは1か所から2か所になりました。このエージェントのオンボーディングと、当社システムへのアクセス提供を全て1か月以内に行い、ホリデーシーズン後には通常時の規模に戻します。これはとても大変です。

内製化プロセスの開始時、エージェントチームの内製化プロセスも開始しました。各コールセンターサイトと協力し、エージェントアカウントのアクセス付与のためのテンプレートとプロセスをEメールテンプレートで作成しました。さてどうなったでしょう？

BPO（業務アウトソーシング）サイトのトレーナーがスプレッドシートを作成し、各サイトに3人までトレーナーがおり、エージェントからのリクエストを送信するやり方は各々違いました。さらに、各サイトのIT部門にそれぞれのAD管理方法がありました。エージェントチームにも複数のアカウントユーザー名とパスワードがあるため記憶せねばならず、この社内事情でお客様にサービスを提供していました。

私たちはエージェントの仕事をより困難にしていました。手動のアカウント管理、作成、無効化をするのに、平常時の人員とディックススポーティンググッズの正社員の半分が必要でした。ホリデーシーズンの、7つの正社員を有するITサービスデスクがこの有り様でした。私たちはレポートの曲芸をしているようでした。当社のシステムにアクセスができる人は誰か、何がプロビジョニングされたか、理解する必要がありました。

当社のコストは急増しました。コールセンターの離職率は必ずしも高くありませんが、新卒者や定年退職後の人員を追い続けることは、非常に手間もコストもかかる価値の低いタスクでした。何とかシンプルにしなければ、やっていけませんでした。

ここでエドと私で、Oktaと業務を始めた時点で当社が設定したゴールをご説明します。

１つ目は、Oktaがコーチとなってくれ、エージェントチームにとって当社ツールへのアクセス取得が容易な方法にすること。よりよいサービス提供をするためよいツールが必要でした。2つ目は、エージェントチームのアカウント管理を当社の外部（BPO）に委託すること。私たちはエージェントの管理をやめ、BPOを管理する仕事をすることにしたというわけです。3つ目はコスト削減です。迅速なアカウントのプロビジョニングとプロビジョニング解除がライセンスの費用管理の要でした。

エド・ハイザー：

それから、シームレスなホリデー対策が必要でした。そのため、私たちはホリデーの人員急増対策について論議しました。短時間でエージェントをオンボードし、短時間で仕事を学ばせ、また、短時間で人員を削減する必要がありました。これがOktaとの協業での主な目標でした。私たちは、繰り返し実行可能なプロセスが必要でした。

それから、1社のベンダーパートナーに縛られることも避けたいと思っていました。2社、3社、より多くのベンダーもしくは、好きなベンダーだけと業務をする場合でも、シンプルで繰り返し実行可能なプロセスで対処でき、ユーザーアクセスの監査が可能なことも必要でした。

Okta内であっても、ID管理テーブル経由の当社のアーキテクチャでも、私たちは誰がどのアプリケーションを使用しているのかを確認する能力が必要だったのです。

では、アーキテクチャについてご説明します。

これが当社のBPOセンターです。このコンタクトセンターでは、エージェントがワークステーションにおり、カスタマーサービスエージェントが電話を受けたり、チャット対応をします。これらのエージェントのプロビジョニングはActive Directory内でBPOによる実行されます。それから、Okta ADエージェントをデータセンターにインストールしてもらい、これにより高可用性を実現しています。

2つのデータ絵センターにActive Directoryエージェントがインストールされているので、データ損失の心配はありません。そこからBPOはそれぞれのスポークを管理します。彼らには自分が担当するOkta Spokeのアクセスがあり、Spokeへのインポートは各自責任を負い、かつ、Spokeはディックススポーティンググッズハブにアクセスします。

Okta Application OrgからOrgという方法で有効にし、そこから当社のActive Directoryにつながります。そして、IDマネージャーテーブルを用いて追加の監査をしています。また、その他アプリケーションの追加機能があります。最終的には当社のActive Directoryテーブルにつながります。これで、コールセンターやコンタクトセンターのエージェントを社内のAD認証アプリケーションにプロビジョニングできるようになりました。つまり発注管理、ウェブ専用オーダー、ギフトカード等です。

またエージェントに、認証が必要な外部アプリのアクセスを提供します。例えば、運送会社のフルフィルメントパートナーなどです。また、認証が不要なサイトであっても、エージェントがワンストップショップとしてサービス提供できるように、当社のeコマースサイトや郵便サービスへのアクセスが付与されています。

それが今日の様子です。私たちはまだプロセスの途中で、あそこのある2つ目のSpokeをs－アドパーティBPOとの間に構築中です。この会社は繰り返し実行可能なプロセスを通して、Oktaスポークに入り、当社のハブに接続します。これはいわば、「当社と業務をするなら、こういうことをやって欲しい」と求め、上手くやってくれました。

エヴァ・シューリ：

Okta統合は、当社のCS運用の価値を向上させました。既存の、そして新しいいBPOパートナーでも、IDのオーナーシップはパートナーの責任になります。これは、当社のIT部門の転換点となっただけでなく、事業のオペレーションチームにも変化がありました。

当社のエージェントチームは、ツールにシンプルな方法でアクセスでき、セルフサービスパスワードリセットもあります。ライフサイクルの自動化に後押しされ、事業のオペレーションはBPOの人数をよく把握でき、監査もスムーズに行われるようになりました。当社のライセンスコストは大幅に削減しました。

重要な点は、自信をもってパートナーと協業できるようになったことです。信頼できるプロセスに従い、エージェントにツールへのアクセスを提供できる。このため、現在新しいBPOをオンボーディングしています。当社のテクノロジーとテクノロジーのアクセスは、スムーズに迅速に用意が整うと確信しています。

エド・ハイザー：

当社とOktaは最高のチームです。プロジェクトの始動時には、16のアプリケーションに実装していました。ホリデーシーズンには3倍のユーザーベースがありました。これは膨大な数です。最初の四半期に、ライセンスコストを30％削減しました。これまでに、5,000人以上のライフタイムユーザーがいます。

私にとって一番大事なのは、Okta導入後、重大インシデントがゼロということです。小規模のインシデントはおそらく5件以下でした。7人のフルタイム従業業員、これはエヴァが先ほど申し上げたホリデーシーズンの人員増加に関連するものです。Oktaを導入後は不要になりました。

追加のメリットとして挙げられるのは、サービスデスクのパスワードリセットなどの簡単な仕事が大幅に削減されたことです。これは目覚ましい変化でした。Oktaneに心から感謝したいと思います。それからOktaチーム、トム、マーク、ありがとうございました。