ITILのシステム構築時のカスタマイズはどこまでやるべきか？

長年、ITIL関係のシステム構築に携わって来ましたが、必ずと言っていいほど実施するのが既製品を自社の文化、運用に合わせてカスタマイズしてほしいという要望対応です。
今回、カスタマイズはどこまでやるべきなのか？について考えてみたいと思います。

多種多様なカスタマイズ要望について全て考えるには、この記事ではページが足りませんので、良くある要望を1つずつ取り上げて考えていきたいと思います。

第1弾は、
『自社の運用にあわせて、項目のラベル名を変更したい』
です。

ラベル名を変更する程度なので、簡単にできるという考えで安易に依頼されますが、本当に実施して良いのでしょうか？

当然、利用者としては、現行ツール(文化、用語)で利用できた方が、システムが変わっても、同じ認識で利用できるため、ラベル名を変更した方が利便性は高いです。

ただ、システムを構築する背景、目的によっては、項目のラベル名を単純に現行にあわせて変更することはお勧めしません。その例を以下に記載します。

①継続的な改善を行うための分析を行いたい。

こちらが目的の場合は、現行のツールの項目では分析できていないから、新システムを構築したいという事になります。

単純に現行の項目にあわせて新システムの項目を用意しても、利用者には都合が良いかもしれませんが、管理者にとっては何も改善されない結果になることがあります。

②ITIL準拠の管理を行いたい

ITILの良い点の1つに、『全国で用語が統一される』点があります。
ITILの用語を利用すれば、部署移動者、転職者でも用語の意味が分かり、共通認識で行動することが可能になります。
安易に自社の文化の用語に変更すると、組織変更、人材の移動に耐えられない組織(システム)になりかねません。

③既製品をカスタマイズして構築する

既製品をカスタマイズしてシステム構築を実施する場合、ラベル名が変更になるだけで、既製品のマニュアルが使えなくなります。
ラベル名を変更すれば、利用者が慣れる工数は削減できますが、マニュアルを作成する初期投資の工数は増加します。
また変更したラベル名のシステムのマニュアルを、誰がメンテナンスするのかという課題も発生します。

ラベル名変更は、技術的にも簡単ですので実施するのは楽ですが、一度、システムを構築する背景・目的を再確認して、実施する/しないを再確認してみても良いのではないでしょうか？