システム老朽化更新は絶好の業務改善タイミング
みなさん、こんにちは。かりんこラボの坂本です。
今日はシステム老朽化更新についてのつぶやきです。
この時に、今の機能・画面構成のまま新しいシステムに載せ替える単純移行はよくある話です。
新しいプログラミング言語や環境で作り直すので、多少動きが早くなったり、若干の操作性見直しは行われますが、基本的には同じ。
私も今までこういった単純移行の仕事にいくつか携わってきましたし、その時に利用者の方から「旧システムと同じだからスムーズに移行できて良かった」と聞けば、要望に応えられたと信じて疑いませんでした。
ですが、「以前と同じ」ということは果たして本当にいいことなのか、実は何も改善されていない、ということではないのかと考えるようになりました。
今回のつぶやきは、私自身の反省も踏まえて、このタイミングでの業務改善について考えてみました。
利用者側の意見
情シス・開発担当者が「老朽化更新で作り変えの必要があるので、もし困ってることがあれば、改善しますが何かありますか？」と聞いた時、システム利用者がベテランであればあるほど、「困っていないので今のままで大丈夫です」という言葉が返ってくることが多いです。
それは本当にそうなのでしょうか。
利用者のシステム利用期間が長くなればなるほど、ムダが無駄と思われず、こんなものだ、と思うようになります。
またシステム設計当初のコンセプトや、経緯を知っている人がいなくなっていることで、なぜこうなっているのかわからない部分があっても、それを誰も不要だと断言できないようになっています。
きっと、誰も自分と関係ないところについて、無駄だとも要らないとも言わないでしょう。
業務改善とシステム変更を一緒にできるベストタイミング
思い切った業務の見直しを行うとそれとシステムが合わなくなり、システムも変えなければならないことが多々あります。
そんなときに、システムは数年前に変更したばかりで減価償却も済んでない、改修の予算もないとなると中途半端なままの業務見直しになり、効果が得られなくなります。
老朽化更新では大抵予算も期間も確保されているので、そのタイミングはまさに見直しのベストタイミング、ここでやらないなんて、もったいない。
システム的な面では過去の技術ではできなかったことができるようになったり、周辺システムが構築されていることによって、連携ができるようになっていたりします。
業務の面からすると、昔は必須だった作業が今は不要になっていたり、注力する部分が変わっていたりします。
人も、仕事の流れも、技術も変化しています。
老朽化更新のタイミングは、必要かどうかわからない作業を見直し、人の作業とシステムの繋がりを再確認し、新しい考えで再構築することができるタイミングです。
今いるメンバーが、共通の認識で業務を理解し、将来に向けての目標を共有できる絶好の機会なのです。
業務改善する理由
現場が混乱するから、業務の流れも、システムの操作方法や画面や帳票の見た目を変えたくない。
確かにこれは理解できます。ただ、混乱はずっと続くわけではありません。数週間、数ヶ月したら慣れるでしょう。
でも、もし、この混乱を恐れるあまり無駄な作業や効率の悪い仕組みをそのまま続けるとしたら、それは、その無駄を次世代にも引き継ぐということでもあります。
新人さんや部署異動してくる人にその無駄を「よくわからないけど、前からこうだから」という理由で伝えていきたいと思いますか？
より良い物やサービスを作ったり提供したり、その本来の仕事を円滑にするためにシステムがあります。
そして、もっと働きやすい環境にするために業務改善を行い、その延長にシステム改善があるのです。
移行までの苦労、運用が始まってからの少しの期間の混乱を避けるためだけに、「ただ同じ」にしておくことは、結局は「仕事」の本来の目的を見失っているように思えます。
さいごに
ということで、私なりに思うことを色々と書きましたが、やはり現実はそんなに思い通りにいかないと思われることもあるでしょう。
ですが、安易に「今と同じ」という選択をするのではなく、少し立ち止まって、何のために？ということを考えることが、業務改善の第一歩だと思います。