今までの IT の流れでは、「ユーザの市場変化への対応力の要求」のドライブで「変化対応力」や「迅速性」が求められ、川上の開発は様々な新しいテクノロジーへの対応が余儀なくされ、その要求スキルもエスカレートしてきた。
一方、川下といわれていた運用は、運用ツールが様々に提供される中、運用ツールのテクノロジーへの依存は、運用コストの削減という大命題からますます自動化テクノロジーへの依存体質が高まったといえる。
残念ながら、ますます複雑化する IT 環境を運用する上で、運用コストの削減や、効率化を図るためには避けようがない選択肢だったといえる。
しかし、本当に運用コストは削減できているのだろうか？
サイロ化されたテクノロジー ドメインごとの運用の自動化は運用プロセスの多重構造を生み、複雑化することで、かえって無駄を発生させてはいないだろうか？
サービス管理を ITIL などを参照モデルとして実施している組織は多い。
インシデント管理、問題管理、そして変更管理に取り組み、変更管理の成功には構成管理が重要であることが身を持って理解された時、これらの管理プロセスの全体像を俯瞰し、明確なゴールへのロードマップなしには、バランスのよいプロセス間連携を実現するだけの自動化システムの構築が非常に困難であることがみえてくる。
それは、クライアント環境の運用管理にもあてはまる。
「PC や モバイルぐらい・・・」
などと、高をくくっている経営者がいたとすれば、いずれ本当に痛い目に合うことぐらいは容易に想像ができる。
今までのIT 運用エンジニアの求人スキルはテクノロジー（DB、インフラ、ネットワーク、セキュリティなど）であったものが、それに追加して運用プロセスの理解や、プロセス改善の提案力など、よりプロセス指向な人材への要求が高まっていくだろう。
それは、サービス指向なユーザの要求が高まれば、なおさら、川上、川下という流れはなくなり、より、還流する川上、川下の別がなくなる環境になっていく。
運用においても「PDCA を考えて・・・P （Plan）、D （Do）、C （Check）、A （Act）・・・」、というフレーズを聞くようになったが、デミングサイクルのそれは品質管理、つまりサービス品質の維持、向上という継続的サービス改善において有効であって、運用の計画、実行を指しているのではない。
「P と D は実施している・・・」
そもそも、計画（P）は、実行（D）と測定（C）、改善（A）を計画していなければ、品質管理をすることはできない。
このレベルの理解は、つまり、運用者における運用プロセスの計画や設計は未だ未成熟であり、今後おおいに改善の余地があると考えられる。
IT 運用エンジニアとして有用なスキルとなるであろうプロセス指向性をIT資産管理プロセスの分野で持っておくのは将来有望なスキルといえるのではないだろうか。