当社のチームは、80以上のドイツの顧客アプリケーション向けのアプリケーションサポートサービスを提供しています。 5年以上にわたる協力により、信頼関係を築いてきました。 約1年に1度、顧客は経費を使い果たし、チームのコストとそれが機能する品質を調べ、さらに数十または2つの内部アプリケーションを外部委託することにします。
私たちの顧客は、サーバーとオフィス機器の大手メーカーです。 私たちに来るアプリケーションは、主にさまざまなレベルでの会計、販売計画、注文、およびレポート用に作成されます。 また、SharePointの内部企業ポータル、および大規模組織のSharePointに通常巻き込まれるすべてのもの（募集、ドキュメント管理など）もサポートします。
私たちのチームは、SharePointおよび.NETアプリケーションに対して 2、3、4行のサポートを提供します。 インシデントを解決し、バグや問題を修正し、必要に応じてアプリケーションコードを変更します。 また、ゼロからの開発にも取り組んでいますが、これは別の記事の話です。
この5年間で、知識の伝達を4回実施し、共有したい経験があります。 後で予算とスケジュールに適合し、将来のサービス開始時の問題を回避するための内部慣行、移管の計画方法。
サービス移転計画
計画を立てる前に、 2つのドキュメントをリクエストします 。
- 以下を含む各アプリケーションのサービスの説明：
- アプリケーションの簡単な説明：目的
- 自動化するビジネスプロセス。
- おおよそ何をすべきか：インシデントをクローズし、定期的なメンテナンス作業を行い、監視し、問題を解決するなど。
- 各アプリケーションへの質問に回答するためのフォーム：
- アプリケーションを使用するユーザーの数。
- それらは内部または外部です。
- キーユーザーはいますか？
- 年間平均して解決されるインシデントの数など
また、利用可能なドキュメント、コード、および可能であればすべてのインシデントレコードのセット全体をリクエストします。 各アプリケーションのレビュープレゼンテーションをいくつか作成し、それを理解している人に質問することができます。
転送されたボリュームの
転送されたアプリケーションごとに、以下を計画します。
- 定期的な知識移転セッション。
- アプリケーションの開発環境開発、コード解析。
- ドキュメントの作成または追加（ビジネスプロセス、テスト計画など）。
- インシデントと問題のレビュー、インシデントに関する知識ベースの作成。
- 現在のサポートグループのインシデントに取り組む（彼らは仕事をします-私たちは見ています）;
- 獲得した知識をサポートチームに転送する。
- 現在のサポートグループの監督下で作業します（作業を行います-彼らは保証します）。
サービス移転の計画は、通常のプロジェクト計画に似ています。 難点は、アプリケーションの分析で到達するラインを自分で設定することです。 コードがどの程度完全に理解されるか、ビジネスプロセスをどの程度真剣に理解する必要があるか、アプリケーションが実行される環境をどの程度正確に再現するか。 どこに滞在するかについての特別な勧告はありません。 一般に、それがどのように機能するかが明確であるときに停止し、詳細を自分で理解できるようになりました。 これらの詳細は、最初の6か月-現在のサービスプロバイダーから1年を区別するものです。 最初は、問題をより長く、時にははるかに長く解決します。 知識の移転が安価な場合、最初はサービスが非常に遅くなり、逆もまた同様であることを顧客に説明する必要があります。 顧客の予算とアプリケーションの中断のない運用の重要性を考えると、顧客との妥協点を探す方が良いでしょう。
計画に加えて、この段階では、評価で定めたリスクの登録を作成します。
重要 ： 必要なすべての情報をすべての関係者に時間通りに届ける必要があります。 特に初めて、サービスを外部委託することは非常に不快な場合があります。 人々があなたを信頼することを学ぶことは重要です。このため、あなたの行動はできる限り明確で透明でなければなりません。 仕事の状況に関する報告は定期的に行ってください。 期限に間に合わない、または台無しになった場合、顧客はできるだけ早くこれについて知る必要があります。
移行開始
計画の準備ができたら、契約に署名し、チームを編成して、開始できます。
知識移転は、計画通りに進行する他のプロジェクトのように見えます。 あなたの心に合った管理方法論を使用できます。 2週間のScram反復を行ったところ、完全に機能しました。 Prince 2によれば、プロジェクト文書のスタックが作成されました。
他のプロジェクトと同様に、突然、職務明細書に含まれていないことを行う必要があります（これは1つのビジネスケースではなく、3つのビジネスケースであることを忘れていました）。 あなたはどこかで仕事の複雑さを過小評価していることが起こります。 あなたが経験豊富なマネージャーである場合、このリスクに対するバッファーもあります。
しかし、私たちが知識移転のプロジェクトでのみ遭遇した困難、すなわち強い抵抗があります。 顧客の環境は均質ではなく、プロジェクトを外部委託するという経営陣の決定にあまり満足していない人がしばしばいます。 多くの場合、現在のサービスプロバイダーはドキュメントの転送をボイコットしたり、ナレッジ転送セッションに参加したり、知っておく必要があることをすべて伝えたりしません。 この場合、できることはエスカレーションだけです。何も起こらない場合は、積み替えの費用を増やします。 知識の移転が始まる前に、この状況とそれを扱う方法を議論する必要があります。もちろん、この項目はリスク登録簿にあるべきです。
サービス翻訳プロジェクトの終了時に、次のものも提供します。
- コード変更の推奨事項。
- サービスを開始する準備が整っているチェックリスト：何が行われているか、何が計画されていないか、なぜか。
- 新しいサービスのメインプロセスの予備バージョン。
- もちろん、軽量化された計画による新しいサービスのリスク登録。
- 学んだ教訓：何が間違っていたのか、次回はそれにどのように関与しないのか。
さらに、サービスマネージャーへの転送のためのプロジェクトマネージャーからの作業の受け入れ、公式のサインオフを行う必要があります。
もちろん、サービスマネージャーは、サインオフ時よりもずっと早く作業を開始します。 知識を移転する前であっても、通常、護衛チームの規模はそれに沿ったふりをします。サインオフの時までに、チームに関する我々の仮定は確認され、調整されるだけです。 サービスマネージャは、メインサービスプロセスの予備バージョンの作成に関与しています。
これらのプロセスは以下を説明します。
- イベントログがチェックされる頻度
- チケットをクローズするために別のチームの助けが必要な場合の作業方法。
- システム内のチケットを適切に閉じる方法など、サービスが時計のように機能しない場合。
サービスの最初の数ヶ月で、これらのプロセスはデバッグおよび変更されます。 予備バージョンから、完成した作業バージョンに発展します。 これは、もう1つの透明性ツールです。私たちが何をしようとも、お客様にとって予測可能です。
サービスチームをトレーニングし、現在のサポートサービスの監督下でサービスを提供しようとすると、サービスマネージャーの負荷が翻訳プロジェクトマネージャーの負荷よりも大きくなることがあります。 もちろん、彼はSLAについて話し合い、サービスの提供に関する契約書を作成する必要があります。 したがって、サービスマネージャーは、プロジェクト全体でサービスの翻訳に精力的に取り組んでいると言えます。
問題をさらに減らすために、後にサービスチームで働く人々は必然的に知識の伝達に参加します。 これは、将来のチームの中核です。 翻訳プロジェクトを完了した後、チームは新しい知識を習得するのに役立ちます。
サービスが3〜6か月で少し落ち着くと、サービスを改善するプロセスを開始します。 かんばんに基づいています。 このプロセスは、サービスのコストを1.5倍削減するのに役立ちましたが、これは次の記事のトピックです。
投稿者： Fkleto4ku