「システムを導入する」 という事に対する
私の位置づけは “業務の見直しのきっかけ” に尽きます。
単に紙データを電子データに変更しただけで
今までと同じ業務をしているというのであれば
システム導入のメリットってあまり感じませんよね？ (￣▽+￣*)
当然電子化されることによって、
手書きミスや探す時間の削減にはなるのですが、
それだけでは “もったいない” というのが私の本音です。(^O^)
またこれは既存システムから新システムへの移行についても同様です。
そして更に言ってしまえば、そのシステムが大規模なものなのか簡易ソフト規模であるかも問わず同じです。
システム導入にあたっては、可能であればシステムを導入する前に
「To-be（あるべき姿）」 を描く事ができれば良いのですが、
導入しようとしているシステムで何が出来るのか分からないのに
「理想像を描け！」 というのは非常に困難な作業です。(^▽^;)
ましてやシステム（ソフト）は千差万別でそれぞれが個性を出そうとオリジナル（っぽい）機能を搭載し、「これからの時代は○○が必要です！」 と主張しています。ありがちなコピーですね…たはは （苦笑）
さて、下記に理想的なシステム導入の流れをざっくりと書いてみましょう。
「To-be（あるべき姿）の作成」（業務をどうしたいのか理想を描きます。）
「As-isの作成（現状把握）」（現状を把握します。）
↓
「システム導入の要件定義」の実施を行います。
↓
「システム設計（設定）」を行います。
「社内の業務（運用）ルールを構築します」
※ここでシステムと業務のギャップを埋める作業が発生します
↓
「システム稼動」を迎えます。
注）「To-be」 において “どうしたい” という点が分かりづらければ「○○に困っている」という視点で具体的に列挙することから始めると少しずつどうしたいのかが見えてきます。
非常に簡単に書きました。（笑）
システムのテスト稼動などといった工程は思いっきり省略しています＾＾；
ここでポイントとなってくるのが※印で表示した
「システムと業務のギャップを埋める作業」 です。
私は人事系のシステム導入が得意なので
人事系システムを例に書いていきますが、
例えば 「就業管理システム」 を導入して
タイムカードのデータと 「給与計算システム」 の処理を
自動化しようとする場合・・・ ヽ(*・ω・)人(・ω・*)ノ
Ａさん…３月３１日の夜中から翌日まで徹夜残業を行いました。
Ｂさん…４月１日の早朝から早出出勤（早出残業）を行いそのまま就業開始を迎えます。
ちょっと考えてみましょう。
給与の締め日が月末３１日だとすると、
Ａさんの徹夜残業分は３月度のお給料で支払われます。
Ｂさんの早出残業は４月１日分の早出残業なので４月度給料で支給します。
このような場合において、
ハンド管理、ハンド計算であればすごくシンプルに処理できますが
いざこれをシステムで自動化しようと考えると単純にはいきません。
ＡさんもＢさんも働いた時間帯は全く同じであるのに
別の月のお給料として計算をしなくてはならないのです。
さてどうしましょ。
・システムの設定に仕掛けを考えなくちゃ、
・就業規則で対応できる考え方はないものか、
・いやいや就業規則そのものを見直してしまえい！
・そうそう、上司には部下の就業管理責任があるよね、
・管理者研修もしっかり実施しなければいけないよね、
・そもそもそんな形態の残業が必要ってどんな業務計画してるのよ？
などなど、たった一つの案件でやらなくてはならない事や
業務そのものの見直しに至るまでギャップ解消は拡がって行きます。
そうそう、化学系の会社などで変則的な残業なんてのも面白いものです。
実験の化学反応を調べるために、一度定時になったら帰社し、
晩御飯を食べて４～５時間後に会社に戻ってくる。
夜中３時に会社に戻ってきた場合は普通残業なの？
それとも早出残業なの…？などです。（苦笑） (￣_￣ i)
システムを導入、そして自動化しようとすると
かなりシビアにルールを決めなくてはならない事案が沢山出てくるので
非常に業務改善のやり甲斐があるというのが率直な感想です。
最初の方にも書きましたが
これは導入対象の企業規模に左右されないと私は思います。
当然、企業規模の大小でインパクトの違いや
考慮しなくても良い箇所、深く考慮しなくちゃいけない箇所は
発生してくるのですが基本的な考え方は殆ど同じです。
いかにそれをきっかけに業務の見直しを行うか？！ (￣∇￣+)
そしてシステム（ソフト）で出来る業務はシステムにやらせ、
人にしか出来ない仕事にいかに業務スライドを行うことが出来るかだと思うのです。
本日もここまで読んでいただき誠にありがとうございました。m(__)m