Perlの開発者、ラリーウォールさんが提唱したプログラマの美徳の一つに「怠惰」というのがありました。
怠惰なプログラマは、怠惰であるがゆえに単純な作業の繰り返しを嫌って、どうにか効率的に作業を完遂できるかを工夫します。
結果的に、マニュアルの作成や作業の自動化など、より効率的に仕事が行えるようになるという事です。

このように、IT業界にいる人であれば、もともと手作業で行っていた各種の事務処理などを効率的に進めるためにコンピュータ・システムの構築・運用を行うのが仕事ですから、自動化こそが正義という方も多いと思います。

ただ現実社会では、自動化を進めたことによる困ることも出てくるわけです。
一つは、経営者／マネージャーが「業務を効率化する」という場合は、大抵、「コスト削減」「利益を出す」というお金メインの考えです。
これにより自動化を推進したメンバーが、周囲との摩擦や評価面で報われないといったケース。

1つは「自動化」の保守に関すること。
大型の基幹システムからデスクトップのRPAのロボットまで、安定して自動化で動いているうちは良いのですが、ある日、突然に動かなくなって困るわけです。

どのように自動化されていたのか、往々にして作った人が退職していて、途方に暮れるといった話もちらほらと聞きますし、作った人でさえも、時間が経つにつれ忘れていることもしばしばです。
私自身も大昔に作ったプログラムを持ち込まれて「うわぁ！」となる事もありましたし、当時の担当者も制作を依頼した会社も無くなったプログラムの分析・改修を依頼されて「うわぁ！」となったこともありました。

そして省力化した結果、より少ない人数で業務を回せるようにはなりますが、より優秀な担当者でないと回せないという現象が起こります。
つまり、自動化された非常に広い工程を、全て把握・保守出来る能力が必要になるためです。

そして少数精鋭で回す体制は、それぞれのメンバーの負担が大きくなりがちです。
一見して「効率化」すれば熟練度が低い社員でも出来るようになると思われるが、もともとバックオフィス業務のようなものは、低スキルの人がこなせるものではないわけです。

これが進むと、自動化が進むことで、ある種の業務の属人化にもつながります。
全体構成が分かり、自動化ツールを使いこなせる人となると希少人材になってしまうわけで、これを回避しようとすると、手作業で分かる領域に業務が引き下げられるわけです。

極端な例では「ワシはパソコン、スマホは使えん」というメンバーに合わせて、業務を設計するという事になるわけです。
「効率化」と「非効率化」を長年かけて、行ったり来たりするのです。
もっとこじれると、効率化している風に装うための謎の無意味な新システムの導入をアピールする社員が出てきます。

システム導入やその後の「自動化」導入も、作った後の保守・メンテナンスが大事なのです。