デジタル時代のサービスマネジメント

scopismblog

サプライヤの分類:フレキシビリティを標準化する方法

Source:https://www.scopism.com/supplier-categorization-siam/
[ This article got permission of both Scopism Claire Agutter and this article’s author Simon Dorst with DIG2 Next Inc. (ePlugOne Educational Services) and translated into Japanese. ]

この記事は、Scopism Claire Agutterさんおよびこの記事の著者のSimon Dorstさんの両者の許可をDIG2ネクスト株式会社(ePlugOne教育サービス)で取得して日本語訳したものです。

Scopism-1
このブログでは、Simon Dorst(ITIL Zealotでも知られる)がSIAM環境で標準化とカスタマイズの間で取り決める必要がある繊細なバランスについての考えを共有しています。 SimonはSIAM Professional Body of Knowledgeのリードアーキテクトの一人であり、ここで彼のSIAM経験の一部を共有しています。ありがとうSimon!

■サプライヤ管理の標準化

Scopism-2 私は以前、SIAM環境におけるサプライヤ管理の重要性、特にサプライヤ、契約、リレーションシップ、パフォーマンス管理の違いについて書きました(こちらの記事参照)。ここでは、サプライヤ管理の標準化について取り上げたいと思います。

一般的に、標準化は、自動化、手続き化、モデリングなどのレベルを向上させることが多く、より効率的なサービス価値の保証を提供することができるので、私たちは標準化が大好きです。たとえば、緊密にコントロールされた標準オペレーティング環境(SOE: Standard Operating Environment)は、非常に変化するハードウェアとソフトウェアを使用するBYOD(Bring Your Own Device)環境よりも管理しやすいと考えられます。しかし、その中には困難があり、標準化はフレキシビリティを制限し、フレキシビリティ(または「アジリティ」)は異なる要件をより正しく扱うためには必要です。あなた自身がユーザの立場に立ったとき、制限された定義済みSOEよりもBYOD環境の自由な状態の方がより嬉しくなりませんか?

あまりにも多くの標準化はフレキシビリティを制限していますが、しかしフレキシビリティがあまりにも高いと、サービス提供の効率性(および多くの場合は有効性も)が低下します。

この挑戦の実例はたくさんあります。私のお気に入りのものは、(ITILベースの)変更管理であり、標準化を重いものにするとアジリティとフレキシビリティが不十分になるプロセスが要求されました。1回の変更諮問委員会(CAB)は、1週間に1回、厳格な承認とテストプロセスのステップをすべて理解する必要があります。しかし、これは特定の変更に対してのみであり、確かにすべての環境ではありません。ところで、これはITILの欠点ではありませんが、しかし多くの場合に認知されたITIL原則のドグマ的な適用です。 1つのCABですべてを支配する vs. 1つの変更ごとのCAB!
Scopism-3 この種の実装が、ITILと変更管理に悪影響を与え、ブロッカーや過度に官僚的に見えることは間違いありません。変更管理を説明するとき私が好きな表現は「horses for courses:餅は餅屋(向き不向きがあること)」です。緊急または標準的な変更と同じようにマイナー、ミディアム、メジャーなどの変更カテゴリは「標準化」に役立ちます。しかしそれにもかかわらず、さまざまなタイプの変更に対して、カスタマイズされた、よりフレキシブルなアプローチを可能にします。そしてそれは始まりに過ぎず、さらなる差別化は異なる顧客や異なるサプライヤのためのさまざまな変更の「標準」を盛り込むことができることです。また、西部開拓時代の「混乱状態」を起こすことなく、バイモーダルモデルやマルチモーダルモデルの導入は「テーラリング」を可能にします。多くの場合、分類は時間とリスクの慎重なバランスの結果であり、そのようなバランスのとれた決定を行うためには、ガバナンスと説明責任の適切な関与が必要です(例えば、緊急の変更を「宣言する」ことができる人…誰でも、ユーザ、顧客、マネージャ?)。

SIAMとサプライヤ管理に話を戻します。 SIAMエコシステムでは、多くの(おそらく数十の)サプライヤが存在し、サプライヤ管理はSIAMの土台の1つです。ファンデーションとプロフェッショナルBOK(ここから無料でダウンロード可能)と認定トレーニングでは、個々のプロバイダとの契約やアグリーメントにエンドツーエンドの測定を含めることがどれほど重要かについて話しています。しかしながら、これらの契約上の要件や測定以上に、異なるプロバイダ間のコラボレーションを確立することも重要ですし(全体はその部分の合計よりも大きい)、ナレッジ共有と継続的な改善に重点を置いています。この多くは、測定および報告フレームワーク、構造要素、委員会、フォーラム、ワーキンググループなどのガバナンスのアーティファクトの確立を通じて達成されています。 これらのマネジメントを標準化し、定義された汎用的な契約テンプレート、レポート構造、コラボレーションアグリーメント、構造要素の中の役割の割り当てなどをすべてのサービスプロバイダに使用できると考えるのは愚かなことです。

SIAMでは1つのサイズは間違いなくすべてにフィットしません! (In SIAM one size definitely does not fit all!)
Scopism-1

■サプライヤの分類

いくつかのプロバイダはサービス提供に非常に「関与」しており、そのスタッフは顧客サイトにいる可能性があり、特定のビジネス要件を満たすようにサービスをカスタマイズされているかもしれません。これらのプロバイダにとっては、一方ではこれを反映したカスタマイズされた契約が求められますが、他方ではSIAM構造要素とプロセスの多くでより明確なエンゲージメントが求められます。

他のプロバイダは、サービス提供の「コモディティ」側でより多くのことをしています。彼らは恐らく多くの異なる顧客に「標準的な」サービスを提供し、顧客の特定のSIAMアプローチに合うように、デリバリプロセス、レポート、エンゲージメント、契約を変更する欲求はほとんどありません。 標準化され過ぎたり、いかにもカスタマイズされ過ぎたりするのを避けるために、私はサプライヤをこのコンティニュアムに分類することをお勧めします。たぶん4つの異なるカテゴリを使用(または5,10、または… それぞれの新しいカテゴリが本質的に他のカテゴリと異なる場合に限り、その中で定義されたサプライヤの管理に価値を付加する)。
  • コモディティ (契約、パフォーマンス、レポートなどにほとんど影響しないクッキーカッター(型抜き))
  • コミットメント低 (例えば、オフサイト、標準「既製」サービス…)
  • コミットメント中 (例えば、オンサイト、カスタマイズされた要素 …)
  • コミットメント高 (完全にカスタマイズされた)

    そこから、可能な限り標準的なバランスを取らなければならないが、必要に応じてフレキシブルに対応した契約、レポート、ミーティング構造などを「標準化」(または少なくとも優先テンプレートを開発)することを始めることができます。

    これはそれ自体新しいことではありません。 ITILのサプライヤ管理はすでにこれを示唆しています(2011 サービスデザインの出版物、セクション4.8.5.3または図4.28)が、これは圧倒的にサプライヤとの間に費やされる時間に焦点を当てており、カスタマイズや実現可能性、あるいはリレーションシップやアーティファクトの修正、標準化、カスタマイズの要件にはあまり依存しません。また、ITILの分類は価値対リスクに基づいていますが、SIAMでの主な検討事項はサービスプロバイダ(または実際にはサービスインテグレータ)が標準化/カスタマイズの取り組みをどのように受け入れることができるかということも必要です。これは、次のような要因によって影響を受ける可能性があります。
  • サプライヤがSIAMモデルに参加し、運用プロセスを修正するなどの必要性
  • 顧客/インテグレータの影響力レベル(プロバイダのパフォーマンス、運用プロセス、ペナルティ/クレジットなど)
  • サプライヤと別のサプライヤの依存性/相互関係(インパクトの一部ですが、全く同じではありません)
  • サービスマネジメントの成熟度とサプライヤのケイパビリティ(SIAMモデルを熟知し、かつ/または採用する)
  • サプライヤのオンサイトまたはバーチャル(オフサイト)の場所

    これらすべては、サプライヤ管理の正しいカテゴリ、フォーマット、または構造を確立する上での追加的な要因(場合によっては複雑化させる要因)です。そして、プロバイダ、インテグレータ、顧客に対する全体的な価値とリスクは、標準化またはカスタマイズのいずれかにあります。

    ■バランスを見つける

    Scopism-4 多くの他のプロセスがそうであるように、「単純な」サービスマネジメントもしくは、複雑なマルチプロバイダSIAM環境の両方において、私たちはカスタマイズと標準化の間のナイフエッジを歩かなければなりません。あまりにも標準化しすぎると、あなたのアプローチが制限的になり、効果がなくなり、ボトルネックが発生します。カスタマイズしすぎるとベストプラクティスが提供できる効率的な利益の多くが失われ、追加のオーバーヘッドによって利益が得られなくなることさえあります。サプライヤ管理はSIAMモデルの中枢のプロセスであるため、さまざまなサービスプロバイダから期待される標準化とカスタマイズのレベルを決定する際に、これをいくつか考え「front foot:上手に立ち回る」ことをお勧めします。もし彼らがオンボーディングする前にプロアクティブ的でなければ、おそらくサービスのライフサイクルを通した進行中の改善として、あるいは少なくともプロバイダを更新するときに。

    「horses for courses:餅は餅屋」とは、勝者を育てる(または成功を育む)正しいアプローチを知っていることを意味します!複雑なマルチベンダのSIAM環境では、標準化とカスタマイズの適切なバランスを認識することが重要です。人材、そして実際にサービスプロバイダは、品質、スキル、戦略、焦点がそれぞれ異なり、さまざまな状況で、さまざまなサービスを提供し、さまざまな方法でオペレーションするために適しています。その方法だけが構造化された効率的な方法で最大の価値を得ることができます。

    この記事のPDFを見る
    ダウンロードも可能です
  • 
    ページのトップへ