ビルドプロセスを補完する全てのリソースは事前にプロビジョニングされ、全ての自動化ソリューションはビジネス要件を満たす必要がある。使用されているツールを評価し、必要に応じてそのツールセットを更新する。古いツールは、当時の手法を使用しているので、その業務に最適な最新のツールを評価する必要があるが、現在使用中の全てのツールを捨てて、置き換える必要があると勘違いをしてはいけない。確実に運用上、失敗に終わる。

　最初の段階から、文書化が重要だ。良く練られた計画は、方向を見失ったときに参照できるロードマップとして利用できる。

ステップ2：実行

　相互接続および全ての依存関係を含め、ITのセルフサービスプラットフォームに含む各プロセスを文書化する。比較的単純なものから始めて、自動化とセルフサービスを使用してプロセスをどのようにリエンジニアリングできるかを調べる。エンドユーザーへのVMの提供は、最も典型的な例だ。レガシープロセスは断片化し、スプレッドシートに負荷を与え、処理時間がかかり、どこにでもエラーが潜んでいる。セルフサービス化したVMプロビジョニングは、高い投資対効果を上げ、このような障害を取り除く。

　古いプロセスを新しいものに置き換えるのではなく、既存のものと並行して自動化プロセスを開発する。そうすることで、いっぺんに切り替えるよりも、システム切り替え中のリスクが少ない。そして、両方のプロセスを並行して稼働することで、新しいプロセスをきめ細かく調整する仕組みを提供してくれる。セルフサービスを認定し、運用開始状態に達するには数カ月かかることもある。

　プロセスの稼働では障害と解決すべき問題がある。セルフサービスプラットフォームが提供するパフォーマンスに関して、もともと非本番環境の一部である場合、IT部門は、より自由裁量を持つことができる。障害は業務に影響を与えないため、システム停止は本番環境と比較して阻害度は小さく、期待もそれほど高くはない。

　両方のシステムを互いに独立した状態に保ち、時間の経過とともに古いインフラストラクチャの使用を減らし、新しいセルフサービスプラットフォームに置き換えていく。

　堅実なプロセスに基づいた成熟したビジネスモデルを持つ企業は、ITサービスの自動化を活用し、新しいアプローチを学ぶためには、大幅な業務改革が必要となる。お金を費やし、並行してシステムを稼働させるために必要なものを作成する。稼働環境ですべきではない変更もある。

　システムが立ち上がって稼働し始めたら、ペーパートレイル（注1）を作成する。ユーザーがセルフサービスプラットフォームを介してITシステムをプロビジョニングする場合、所有権と資産を追跡する従来の方法では十分ではない。プラットフォームを介して関連する全ての書類手続き（もちろんデジタル）を取り込む。CMDBは、誰が何をリクエストしたか、いつそのリクエストが処理され、そのときのサーバやサービスの詳細を確実に追跡する。

※注1：誰かの行動を記録し、証拠として書面に残したもの。

ステップ3：プラットフォームをサポートする十分なキャパシティー

　IT管理者としては、極上で新しく、すぐに恩恵を享受できるセルフサービスプラットフォーム運用の準備ができたにもかかわらず、このサービスをサポートするために「もっとたくさんハードウェアをプロビジョニングするまで待たなければならない」とビジネスユーザーに伝える立場にはなりたくないだろう。セルフサービスの利便性によって、インフラストラクチャとIT利用率の成長を管理するのだ。パブリッククラウド環境でのデプロイの場合、ハードウェアの可用性は問題ではないが、企業は、使用する全てのリソースに対して支払いが必要だ。従って、キャパシティー管理がここでも重要になる。

　一部の企業では、IT利用率を手作業で予測し、ユーザーグループに四半期ごとに予想成長率の提出を求めている。しかし、大部分の大規模な管理プラットフォームは、キャパシティー管理機能が組み込んであり、使用時間の経過とともに将来のキャパシティー消費傾向を正確に予測できるようになる。IT管理ツールは高価であるが、リソースプールのサイズを適切に調整し、適切なキャパシティーでのサービスレベルアグリーメントを満たす機能は、今日の組織にとってツールにかかる費用を相殺する。

　セルフサービスプラットフォームへの移行には、慎重に取り組んでほしい。業務の進め方を変革するだけの威力を持っているからだ。しかし、その場しのぎの解決法などなく、エラーは必ず発生する。必要とする目標を定義するために費やす時間を惜しまず、必要に応じて再調整し、業務プロセスを分析し、そしてセルフサービスプラットフォームの完成度を積極的に高めていく。この全てをやって初めて、セルフサービスプラットフォーム運用の準備が整うのだ。