商用ソフトウェアをアップグレードするための戦略を文書化する方法は?


11

RDBMSまたはサーバーOSを10年近くアップグレードしていません。別のミッションクリティカルなソフトウェアパッケージは20年近く前であり、そのベンダーの多くの期間サポートされていません。私たちの経営陣の中には、これは良いことだと考えているようです-アップグレードを購入しないことでたくさんのお金を節約しました!現在、重要なソフトウェアにはアップグレードが必要ですが、新しいバージョンでは10年前のものはサポートされません。今、私たちのほんの一握りは、最小限のダウンタイムですべてを一度にアップグレードする方法を見つけようとして髪を失っています。

将来これを避けるために、私たちの何人かはIT戦略計画文書の作成を検討しています(これは組織の戦略計画に適合し、ITに関連するより大きな文書の項目を具体化します... IT文書を戦術的にする計画?)代理店の全体的な戦略計画の一部として採用されることを期待しています。上記の問題に対処するために、「ソフトウェアライフサイクル管理」(またはそのようなもの)セクションを組み立ててみました(戦略計画とは別のドキュメントに真鍮のタックが含まれている可能性が高い)。ほとんどすべてのソフトウェアベンダーが製品のライフサイクルと非推奨の計画を公開しています。組織のニーズに合わせてその情報を考慮して、各ソフトウェアの「スイートスポット」を決定するのは簡単です。トリッキーな部分(とにかく私にとって)は、各作品の計画をよりまとまりのあるものにまとめることです。

デスクトップクライアントA、B、C ...がデスクトップOS XとRDBMS Yに依存していることを文書化するにはどうすればよいですか?これらはサーバーOS Zに依存しますが、それらをすべて「スイートスポット」に保持する方法を次に示します。そこに本があるはずですが、私のすべてのグーグルは、それらの戦術をいつ実装するかを決定するための戦略ではなく、単一のソフトウェアをアップグレードする戦術についてだけに私を導きました。


7
すぐに誰かがこれに挑戦しますが、私が見逃してはならないのは、会社がアップグレードにお金を費やさなかった一方で、ビジネスを危険にさらすことです。私たちがしなければならないことの一つは、経営者にアップグレードしないことのリスクを認識させることです。
マイケルハンプトン

3
アップグレードを延期するための専門用語は、「技術的負債」を積み上げることです。定期的なメンテナンスとアップグレードを延期することで、短期的にはある程度の費用を節約できるように見えますが、何年も放置した後にメンテナンスを実行する必要が生じた場合、パイプ業者に支払う必要があります。以下からのサポートの即時アップグレードパス持た$CURRENT-version minus 20 years$CURRENT-versionなど、あなたはおそらく結論に到達します:これらは実際の貯蓄ではなくした経費になります将来の日に支払われます
-HBruijn

1
ライフサイクル管理は、成熟した環境での恩恵のない必要性であり、整理するためのPITAです。幸運を!
HBruijn

回答:


7

あなたは一度に多くの問題を解決しようとしているように見えます(そしてそれは良い考えのようには見えません)。

私が読んだものから:

  • 古いOSとアプリケーション
  • 長期戦略なし
  • インフラストラクチャの文書化の問題
  • インフラストラクチャの重要な部分をアップグレードする緊急の必要性

「重要なソフトウェア」のアップグレード

誰かの決定によりインフラストラクチャが古くなっているのは簡単に理解できます。過去のある時点では、おそらく良いアイデアのように思われました。これは、マイケル・ハンプトンがコメントで書いたものに要約されます。管理者にとって、あなたは賛否両論(リスク)について話しているのです。したがって、経営陣がリスクを冒す意思がある場合、OK(あなたが個人的に考えていることは何でも)であり、これは今後の責任です。しかし、IT関係者の誰かがリスクとは何かを伝えなければなりません。

だから私が最初に探すのは、マネージャーが古いソフトウェアのリスクを知っていたかということです。彼らは言われましたか?

正直なところ、おそらくあなたはそれについて有用なものを見つけられないと思うので、あまり時間をかけないでしょう。これは、「過去5年間、私たちがあなたに言っていたこと」の流れに沿ってあなたを助けることができるものです。

私は単に、そのアップグレードを実行することが本当に意味するものの分析を行います。アクティビティとアクティビティにかかる時間を記載した簡単なスプレッドシートを準備します(わからない場合は、最善の推測を行い、わからないことを明示的に強調します)。ただし、この「アップグレードタスク」は十分に指定されておらず、fix-time / fix-priceとして実行することは不可能です。

このようなリストを作成すると、問題全体を掘り下げるのにも役立ちます。次は、リスクログと必要なリソースのリストを作成します。

最後に、アクティビティのリスト、リスクのリスト、必要な材料/人のリストが必要です。 つまり、アップグレードを日常的な問題として処理するのではなく、プロジェクトとして実行します。 これにより、会社の深刻なニーズを少なくともある程度制御できるようになります。

実行する必要があるアクティビティの分析に問題がある場合は、マインドマップ(私のお気に入りのswはxMind)を試してから、より正式なドキュメントに変換できます。

アップグレードの方法についていくつかのオプションがある場合は、コスト、結果、リスクなど、いくつかの文に要約された可能なソリューション(もしあれば)を管理者に書いてください。推奨するオプションとその理由について言及するのが理想的です。最終的な選択は彼らが行うことだからです-彼らは結局マネージャーです。

たぶん、この特定のケースでは:アップグレードがまったく可能でないかもしれないという言及。

長期戦略なし

戦略的計画を作成しても、今は役に立ちません。IT部門内で作成されたドキュメントである場合、まったく役に立ちません。戦略計画は、ビジネスニーズに結び付ける必要があるものです。

ビジネスニーズの例:2年間で、中国とオーストラリアに新しいオフィスを開設します。

ITタスクの派生:新しい従業員に最悪の事態をもたらし、外国のオフィスにインフラストラクチャを作成し、(おそらく母国語を使用して)新しい従業員にトレーニングを提供し、それらのオフィスから中央への安全な接続を提供する準備をします...

物事がうまくいけば、戦略を立てることができるかもしれません...数ヶ月で?それで、すべてが合意されるまで約半年ですか?

インフラストラクチャの維持と文書化

これは過去の遺産であり、今、あなたは物事を変えなければなりません。優先順位を付けます。ほとんどのことを最新にするために、今やりたいこと/やらなければならないことのリストを作成します。待つことができるものを選択し、粗雑なロードマップを作成します。(このロードマップは、IT戦略がある場合はIT戦略の一部である必要があります。)

うまく行ったものを更新する場合は、日常業務として処理してください。悪くなる可能性のあるもの(費やした時間、割り当てられた人などに関して「大きい」)を処理している場合は、それをプロジェクトとして処理します。

ドキュメントとサービスの依存関係を支援するツールがあります-CMDB(たとえばiTop)。ただし、機能させるには時間がかかることがあり、ドキュメントツールが必要です。最良のアイデアは、誰でもドキュメントの作成/メモの作成を開始できるドキュメント用のウィキをセットアップすることです。30分でwikiをセットアップできるため、物事を始めるのに非常に効果的な方法です。

個人的な注意:古いOSのアップグレードは、(おそらく悪い/欠落している)ドキュメントに言及せずに、巨大なPITAになります。サーバーを新たにインストールし、アプリを移行し、最初からすべてを文書化する方が簡単ではありませんか?


私はまだあなたの答えをもっと注意深く読む必要がありますが、最初に。。。Re "戦略計画の作成は今は役に立たない":現在のプープストームのストーリーは、問題を説明することのみを目的としていました。私たちはそれを橋の下の水として扱い、将来の糞尿の降水を防ぐために一緒に戦略計画を立てようとしています。これをより明確にするために質問を編集する必要があります。
フィンリクソン

1
ええ、私はあなたの意味を知っています。しかし、その特定の文を切り取ったとしても、答えの残りはまだ有効だと思います。:)
Fiisch
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.