失敗例１：従来のメールシステムとの互換性が低かった
A社では現行のメールサーバがかなり老朽化しているという課題がありました。そこで、運用負荷を減らすことと、バックアップ体制の強化による業務の効率化を目的として、クラウドメールを導入しました。
しかしながら実際に導入すると、インターフェースや機能面において従来のメールシステムとは大きく異なっていて、生産性に悪影響が出てしまうように。現場部門から使いにくいという不満の声も多く、半年後に利用をやめ、他社サービスに乗り換えました。
【対策】
運用負荷を減らせることを期待して導入したにもかかわらず、導入前以上に負担が増えてしまうと、本末転倒です。このような失敗を防ぐためにも、現行のメールシステムと導入を検討するクラウドメールの間に、どれくらい親和性があるのかを確認してから導入に踏み切るようにしましょう。
失敗例２：従来のメールセキュリティシステムが使えなかった
社内での検討を重ね、万を持してクラウドメールを導入したB社でしたが、実際に移行してから大きな問題が発生。これまで利用していたウィルス対策や誤送信対策・暗号化などのセキュリティ対策ソフトが、クラウド体制では利用できない、というものでした。
【対策】
このような事態に陥らないためにも、本導入の際は、現在利用しているシステムを継続して使えるのか、を確認しましょう。なお、現在ではクラウド型メールシステムに、誤送信対策やメール暗号化などのセキュリティシステムが加わったオールインワンのパッケージなども多く取り扱われています。
このようにメールシステムとセキュリティシステムがセットになったものを選べば、最初からセキュリティ機能を使うことができるので、別で検討する手間がなくなり、使い勝手が良いといえるでしょう。
失敗例３：ベンダー側トラブルによって左右された
クラウドメールを導入したC社ですが、以前までのメールシステムでは無かった、ベンダー側の改修やトラブルによって利用制限がかかってしまうという負荷が発生したようです。
サービス提供ベンダーの管理するアプリケーションやインフラで何かしらのトラブルが発生した場合、利用企業はその煽りを受けてしまいますが、大抵の場合ユーザ側でのトラブルへの対策は難しく、ベンダー側のサービス復旧を待つことしかできないのが現状です。
また、サービスのアップデート等にともない、利用しているWebブラウザやOSなどの環境を、ベンダー側の要求する基準に合わせる必要が出てくる場合もあります。
【対策】
障害やアップデートなどは通常は頻繁に起こるものではありませんが、万が一起きた場合に、問い合わせ先や、契約条件などをすぐに照会できるよう、導入前に確認する工程を踏むようにしましょう。ベンダー側のサポート体制の充実度も、クラウドメールの利用の際には大事な要因だと言えます。
クラウドメールの導入目的を明確に！
以上の失敗例をふまえると、ベンダーとの見解のすり合わせをしっかりと行い、理解度を深めてから導入を行うと、本記事で挙げたような問題はあまり起きないものと考えられます。
また、コスト削減を行おうはずが逆に高く付いてしまったという例もあるため、何のために導入するのか、どんな導入効果があるのか、どんな運用方法をとるのかをはっきりさせてから、製品の導入を行いましょう。
メールシステムは、企業活動におけるコミュニケーションツールとしてもはや欠かすことのできないものです。クラウドメールを導入する際は、急がずに、情報収集と現場部門のヒアリングを徹底し、万全の体制を持ってして行うようにしましょう。
