SLA – Service Level Agreement

— 更新しました:
SLA – Service Level Agreement
写真: Paradee Paradee | Dreamstime

SLAとは何ですか。また、IT分野における顧客と請負業者の関係におけるSLAの役割は何ですか。

最近、エコシステム、プラットフォーム、ビジネスプロセスを最適化するためのテクノロジー、迅速で機敏な開発と相互作用のための革新的な方法など、基本となると主張する企業の生活に比較的新しい概念がいくつか登場しました。それぞれが本当に意味があり、意味があります。 。もう一つのことは、本質が美しい言葉の後ろにぼやけていることが多く、一般的なファッショナブルな用語だけが表面に残り、徐々にダミーに変わることです。

SLAとは何ですか?

数年前、この一連の最初は重要でコンテンツに満ちた概念は、SLA(サービス品質について)という用語で補足されていました。

SLAは、サービスコンシューマー(主に統合自動化の分野)とIT開発者/インテグレーターとの間の相互作用の基本原則の1つであり、そのような合意の基本原則。

この状況でSLAの概念を切り下げることは、顧客と請負業者の間の関係のパラダイムを切り下げることを意味します。

クッキーは、ほとんどの人が知らない不思議なファイルです
クッキーは、ほとんどの人が知らない不思議なファイルです

多くの企業はこれを理解しており、SLA契約の厳格な遵守を主張する企業もあります。しかし、問題は、最近、私たちが多くの新しい経済的および社会的課題に直面し、企業がそれらに適切に対応するためにあらゆることを行っていることです。したがって、それを提供する構造は、新しい要件を満たす必要があります。これはSLAに完全に当てはまります。2年前と同じままにすることはできません。今日のSLAとは何か、SLAがどのように、何に変換されるべきか、そして1年後に何になるかを理解してみましょう。
従来のSLAは、クライアントとサービスプロバイダー間の合意であり、プロジェクトの品質(エンドポイント)の保証を明確に示しています。

プロジェクトの各段階の保証が特定の合意(中間点)のレベルで規定されている「中間」SLAが存在する場合があります。この場合、ほとんどの場合、SLAは契約の不可欠な部分として作成されますが、ここでのコンテンツのロードは完全に異なります。したがって、契約で何が、どの程度、どの時間枠で行われるかが最も頻繁に規定されている場合、SLAは、それがどのように行われるか、どのような費用で、どの指標が特定の指標として採用されるかを宣言します。

SLA
写真: Joerg Stoeber | Dreamstime

今日、ビジネス上の課題がますます複雑になり、パンデミックを含む一連の危機により、企業はそれらに適応するためのタイムラグを短縮し、新しい方法でより速く、より良く作業することを余儀なくされています。 IT企業が適切に対応しなかった場合。可能な限り短い時間で、複雑なグループ開発手法(アジャイル、DevOps、共有グループ)が、大規模な開発会社と小規模で高度に専門化されたIT企業の両方のほぼすべての専門的なIT構造に採用されました。

もちろん、分散作業、開発者と実装者の急増、およびソフトウェアソリューションを小さなステップに分割して作成するテクノロジーの両方により、迅速な結果を達成し、顧客のビジネス上の問題を解決し、さらには構築または構築の基盤を築くことができます。あらゆる企業の情報システムの開発。ただし、ビジネスソリューションプロバイダーとITソリューションプロバイダーの両方が現在の状況に適切に対応している場合、保証、とりわけSLA内では、大多数が同じままです。これは、SLA形成の原則を変更する必要性を無視すると、必然的にマイナスの結果につながることを意味します。

DevOps-開発と運用
DevOps-開発と運用

このような背景から、新しいSLAが現代のアジャイル開発の方法論と相関することは非常に重要であり、従来の段階への分解はもはやここでは十分ではありません。これで、サービス品質に関する合意は、完了した段階ではなく、プロジェクトの各段階の実装内の各段階に「調整」する必要があります。現在の現実では、包括的なSLAには、開発と実装の保証されたマイクロステージだけでなく、それぞれのインテグレーターの責任も含める必要があります。

ただし、このアプローチは会社に負担をかけます。会社は、これらの条件下で、複雑なプロジェクトの実装を引き受ける準備ができています。このような保証を遵守するためには、主に顧客のビジネスを深く理解するレベルで、インテグレーターのワーキンググループの一種の「浸透」を顧客の「心」に提供する必要があるため、これは容易ではありません。 。開発者は、顧客のビジネスプロセスが実際にどのように配置されているか、したがって、それらを変更する方法を知っている必要があります。そして、これに最適な技術ソリューションを見つけて適応させ、ほとんどその場で改善すると同時に、顧客のエンタープライズワークサイクルの継続性を確保することが、優れたITパートナーの主なタスクです。

ドメイン駆動設計-DDDプログラミング
ドメイン駆動設計-DDDプログラミング

標準的なアウトソーシングの方法でこれを達成することはほとんど不可能であることは明らかです-ここでは、クライアントと請負業者の根本的に異なる形式の作業であり、異なるレベルの相互作用が必要です。現在は「外部IT部門」と呼ばれています。更新されたSLAが真に有効になるのは、この新しいサービスが展開されたときだけです。そして定期的に、顧客とパフォーマーの両方が継続的に彼に連絡するとき(おそらく2週間に1回でも)。そして、これがその仕組みです。

タスクを設定する機能(これはプロジェクトの重要な段階です)は、顧客と潜在的なエグゼキュータの間ですぐに分散されます。開発者/実装者は、最初の日から、内部監査(またはコンサルティング)の重要な役割の1つを引き受けます。このようなスペシャリストは、お客様と一緒に、変更する主要なビジネスプロセスを特定し、ビジネス開発を実装するための戦略と戦術を開発し、これに最適なテクノロジーを選択します。

SLA
写真: Joerg Stoeber | Dreamstime

次に、インテグレーター会社は、原則として、プロジェクトアカウント、アナリスト、開発者、テスター、実装者、テクニカルサポートスペシャリストなどを含む、準備が整った予備から高度な専門家チームを形成します。その結果、既成のIT部門まるでこの会社の中にあるかのように、特定の企業の問題を​​解決することを目的として、文字通りすぐに作成されます。このアプローチの追加の利点は、他の同様に重要なタスクを解決するための顧客のITリソースの解放です。

現代のIT開発者が今日クライアントに提供しなければならない2つの相互に関連する複雑なサービスについて話しています。それは、彼が実装するマイクロステージ(外部IT部門)に分割されたマルチレベルプロジェクトと、提供する通常のSLAです。このプロジェクト内の各ステップの保証された結果。

UXデザイン-ユーザーエクスペリエンスデザイン
UXデザイン-ユーザーエクスペリエンスデザイン

これまでのところ、このアプローチはロシアと東ヨーロッパではまだ普及していません。

それでも、このスキームに従ってすでに多くのプロジェクトが正常に完了しており、ここでは顧客のビジネスの規模はそれほど重要ではありません。大企業と中規模企業の両方で、まだ適切な展開の経験がない可能性があります。独自のITシステムですが、すでにこの問題に根本的に取り組む準備ができています。
ある企業は、このような複雑なタスクを全国規模で解決することはできません。IT開発者、システムインテグレーター、機器サプライヤー、そしてもちろん顧客の意志の共同の努力が必要です。 。このパスは、どのような場合でも私たちによって渡されます。ただし、これは迅速かつ体系的に行う必要があります。