高いシステムを使っているのに、手作業が減らない。だったら入れ替えるべきか。派遣会社のご相談で、何度も出てくる問いです。
派遣会社のスタッフ管理システムについて、よくこう聞かれます。それなりの費用を払っているのに、必要な項目が一覧で出せない。結局、表計算ソフトに書き写して手で整えている。スタッフからの到着の連絡も、メール・電話・ショートメールとばらばらに届いて、見落としが起きる。入れ替えた方がいいのでしょうか、と。
答えは会社ごとに違います。ただ、答えを出す前に決めておくことは、どの会社でもほとんど同じです。この記事では、その順番を書きます。
「どの製品にするか」は、最後に決める
システムの入れ替えの話は、製品の比較から始まりがちです。資料を取り寄せ、画面を見せてもらい、機能の一覧に丸とバツをつける。でも、その丸とバツが自社にとって大事かどうかは、自社で何をしたいかが決まっていないと判断できません。
私たちが最初にやるのは、「やりたいこと」の洗い出しです。いまのシステムの不満ではなく、本当はこうしたい、という形で書き出します。
- スタッフの資格や契約の期限を、一覧で確かめたい
- 到着や欠勤の連絡を、一か所で受けたい
- 勤怠を、請求と給与へ打ち直さずに渡したい
- 取引先ごとの決まりを、担当者が替わっても引き継げるようにしたい
こうして並べると、システムを替えないと解決しないものと、運用や周りの仕組みで解決できるものが分かれてきます。業務を一つずつ聞き取る進め方は、Field Log #007 に書きました。この記事は、その先の「では、どうするか」の話です。
システムに入れる範囲と、切り出す範囲を決める
次に、基幹のシステム（スタッフ・契約・勤怠をまとめて持つ中心のシステム）に何を入れるかを決めます。全部を一つのシステムで持つのが正解とは限りません。たとえば経理の処理は、会計の仕組みに任せて切り出した方が、無理がないこともあります。
範囲は、言葉ではっきり線を引きます。「現場から勤怠を受け取ってから、給与の振込と請求書の発行が終わるまで」のように。それ以外は今回は対象外、と決めておく。ここが曖昧なまま進むと、「DXをやる」という言葉だけが先に立ち、どこまでやれば終わりなのか誰にも分からなくなります。
あわせて、何をもって成功とするかも決めます。手作業を減らしたいのか、ミスを減らしたいのか、利益率を変えたいのか。経営と現場で、ここがずれていることは少なくありません。
画面を行き来するなら、手間は変わらない
システムを足したり替えたりしても、担当の方が一つの作業のために三つの画面を行き来しているなら、手間はほとんど変わりません。入力の場所が変わっただけです。
だから私たちは、ひとつの作業がひとつの画面で終わるかどうかを、大事な判断の材料にしています。機能が多いかどうかより、毎日の作業が途中で別の画面に移らずに済むか。そこを、実際の業務の流れに沿って確かめます。
選択肢は、三つに分けて並べる
そのうえで、基幹のシステムの選択肢を三つに整理します。
- パッケージに寄せる：市販の派遣管理システムに業務を合わせ、契約から請求・給与までを一本でつなぐ
- 同じ役割のものを自前で作る：自社の業務に合わせて、必要な範囲を新しく作る
- いまの仕組みを残し、周りを整える：基幹は替えず、手入力や連絡のばらつきなど、困っている部分だけを置き換える
データを一か所に集めるという意味では、1の形が理想に近いことが多いです。ただ、移行には大きな労力がかかります。途中で止まれば、古い仕組みと新しい仕組みの両方にデータが散らばり、いちばん無駄の大きい状態になります。パッケージを入れたのに一部しか使われず、結局データが散らばったまま、という話も聞きます。
3は地味に見えますが、止まるリスクが小さい案です。2は自社に合わせやすい反面、作ったあとの保守を誰が担うのかを決めておかないと、数年後に同じ悩みが戻ってきます。
どの案にも、向く会社と向かない会社があります。費用も、最初にかかる額だけでなく、数年使い続けたときの総額で比べます。どれがいちばん安くなるかは、会社ごとの条件で変わるので、ここで一概には言えません。
「できない」は、画面に入って確かめる
パッケージを検討するとき、「うちの取引先の決まりには対応できない」という声がよく出ます。それが本当にできないのか、設定を知らないだけなのかは、管理画面に入って確かめるまで分かりません。資料や営業の説明だけで判断しないようにしています。
もう一つ、見ておきたいことがあります。取引先ごとの要望に、これまで一つずつ応えてきたこと。それ自体が、システムを複雑にしてきた根っこであることが多いのです。システムを替えても、その応え方が変わらなければ、新しいシステムもいずれ同じように複雑になります。どこまで取引先ごとに合わせるかは、システムではなく会社として決めることです。
試すなら、先に「合格の条件」を決める
製品を試せる期間があるなら、使わない手はありません。ただ、なんとなく触って終わると、何も決まらないまま期間が過ぎます。
- どういう状態になれば本格的に使うか、始める前に決めておく
- 試す範囲に上限をつけ、業務の全部を一度に乗せない
- 途中で一度、思っていた使い方とずれていないかをすり合わせる
- 最後に、現場の方の声も含めて振り返る場をつくる
ここまでやっておくと、入れてから「こんなはずではなかった」となることが、ずいぶん減ります。
替えるかどうかの前に、出口を確かめる
どの案を選ぶにしても、先に確かめておくことがあります。いま使っているシステムから、スタッフや契約のデータを書き出せるか。自社で持っておくべきもの（データや、ホームページならドメインなど）を、自社で管理できているか。
これができていないと、替えたいと思ったときに替えられません。今回は使い続けると決めた場合でも、出口があるかどうかは確かめておく価値があります。
外部の会社と一緒に作っている場合は、最初に何に合意していたかも確認します。追加の費用の話が出たら、「中身を足す」話なのか「仕組みの形を変える」話なのかを分けて見積もってもらう。混ざったままでは、高いのか妥当なのか判断できません。
何から手を付けるかは、効き目で決める
スタッフ管理、顧客管理、ホームページ、社内の情報共有。システムの話が始まると、全部を一度にそろえたくなります。私たちは、それぞれ「課題は何で、解決したら何が変わるか」で順番をつけることをおすすめしています。売上や日々の手間に直結するものが先で、あった方がいいものは後でいい。
社内の情報共有の仕組みも、立派な入れ物より、見れば自分で動ける手順書の方が役に立つことが多いと感じています。
決めるのは経営。私たちは並べる側に立つ
三つの案は、同じ条件で並べて、経営の方に判断していただきます。私たちはその材料をそろえる役です。
一つ、正直に書いておきます。私たちは、自前で作る案（上の2）や周りを整える案（上の3）を、自分たちで開発することがあります。比べる側と、選ばれる側が同じになる場面です。そのときは、その案を私たちが作る前提であることを、比較の資料にはっきり書きます。パッケージに寄せる案の方が合うと考えれば、そう言います。
替えるかどうかは、それほど急いで決めなくて大丈夫です。やりたいこと、範囲、成功の条件、出口。この四つが決まれば、答えはだいたい見えてきます。業務の聞き取りから始める話は Field Log #007、現場に足を運ぶ理由は Field Log #001 にも書いています。
- パッケージを入れたばかりですが、もう見直した方がいいのでしょうか。
- 一部しか使われていないなら、まずその理由を確かめます。設定や運用で解決できることも多く、すぐに替える話にはしません。
- 自前で作れば、パッケージより安くなりますか。
- 条件によります。作る費用だけでなく、数年分の保守や改修まで含めた総額で比べないと判断できません。
- 相談すると、TLが作る前提の提案になりませんか。
- なりません。三つの案を同じ条件で並べ、私たちが開発する案を含むときはそのことを明記します。
文・片桐 正嗣株式会社TL 代表取締役
ご支援先が分からないよう、社名と一部の内容を伏せています。
新しい記録は SNS でもお知らせしていますX でフォロー Facebook でフォロー