1. 圧倒的に「運用にシステムを寄せる」パターンが破綻しやすい

システム導入を行う際に、まず

「可能な限り現場に負荷をかけたくない」

と思うあまりに、既存の運用を変えずにフィットするパッケージシステムを探そうとすることはよくあります。

しかし、自社の運用に完全にフィットするようなパッケージシステムはほとんどありません。そこで、製品のカスタマイズの柔軟性に頼っていきます。すると、本来の使われ方とは違うシステムの使用となっていき、次第にいろいろなところでシステム側に「歪み」が生じていきます。場合によっては保守の対象外となってしまうこともあります。

そこで選ぶ方針としては以下の2択になっていきます。

  • システムの部分改修を依頼する
  • 結局、CSVなどで吐き出してシステムの外で作業する

前者は想定外の余計なコストがかかります。後者は結局手間が増えただけ、という結果になります。

書類やファイルが詰まった「運用」の箱と、承認フロー図が表示された「システム」のノートパソコンを両手に乗せて悩む総務担当者のイラスト。運用にシステムを寄せるかシステムに運用を寄せるかで迷う様子を表す
運用にシステムを寄せるか、システムに運用を寄せるか、導入時に多くの担当者が迷うポイント

2. ワークフローツールを例に

ワークフローツールは、経理システム、HRシステム、営業関連システムなどとは異なり、部門・部署をまたいで全社に影響を及ぼすシステムです。

ある部署だけ、ある拠点だけ、ある場合においてのみ、特例の申請や承認プロセスが存在していて、これを許容し続けたい場合、ワークフローツールの柔軟性に期待するしかありません。

例えばある拠点では、購買申請について最終承認は所長権限が必要なのにも関わらず、仕入先と所長のスケジューリングの都合上、どうしても副所長が代理承認をし、所長が追認していたとします。

これをワークフローで実現しようとすると、その拠点の特定の購買申請において専用のワークフローを準備する必要があります。ガバナンス上問題がなければ部分的な例外規程でよいかもしれませんが、他の拠点においても同様に例外処理を依頼された場合、管理工数やメンテナンス負荷が跳ね上がっていきます。

システム上、何かしらの理由で例外処理を設けられないとする場合、その拠点においては従来通りの運用を繰り返すよりほかなくなります。これがシステムの外側で処理が始まっていくパターンの始まりです。

3. システムに運用を合わせるなら

システムに運用を合わせるのは、非常にパワーを要する仕事になります。社内のルールやあらゆる業務フローの見直しを行い、どこの拠点、部門の誰が使っても、同じワークフローで承認が回る形に整えます。

しかし、過去、多くのシステム導入をした企業、まさに導入しようとしている企業を見てきて、成功しているパターンは、「システムに運用を合わせる」というケースの方が圧倒的に多いです。

人は変化を好ましく思わないものですので、現行運用に相応のトラブルがあるという場合以外では、運用変更は迎合されないケースが多いです。

  • リスク回避
  • ガバナンス強化
  • 将来的な工数軽減

という不確実性の高い理由では、長らくやっていた仕事のやりかたを変える動機にはなりづらい場合があります。

経営側と現場側の十分なすり合わせが必要で、「不慣れ」以外のボトルネックがあれば一つ一つ取り除いておく必要があります。

4. 運用の整理に手間がかかるパターン

ワークフローに合わせて運用側の整理に着手する場合、

  • ワークフローを要する承認はいくつあるか
  • この申請の承認権限者は誰か
  • 承認は何回(何レイヤー)の承認が必要か

といったあたりの「箱」の整理は比較的容易です。

一方で中身を入れるときに苦労することが多いです。従来「〇〇さんの承認が必要」というように、特定の個人に決裁権が紐づいているような運用の場合、ワークフロー導入のタイミングで整理しておくことが好ましいです。部長職、課長職などの役職に紐づけておいたほうがよく、個人名で紐づいた場合、その方の異動や退職によってワークフローに混乱が生じかねません。また、役職や等級が曖昧なまま組織運営されている場合も、初期設定に時間がかかることがあります。

これらの権限等の整備については、人事制度や評価精度とも無関係ではありませんので、根深くなるケースがあります。「課長級の権限」において承認が可能な申請があったとします。ところが、今まで主任級の人が当たり前に承認していたという事実が明るみに出ると、その主任は権限以上の責任を負わされていた、という不満になりかねないからです。

このような矛盾が存在している場合も、ワークフローツールの導入を契機に一新してしまった方が良いでしょう。

Aさん・Bさんといった個人名に紐づいた複雑な承認フローに悩む総務担当者から、部長・課長・主任という役職ベースのシンプルな承認フローへ整理される様子を示すイラスト。権限の不整備が人事制度や評価への不公平感につながることも表す
個人ではなく役職に権限を紐づけることで、承認フローがシンプルかつ運用しやすくなる

5. おすすめの導入方法

全てを一斉に変えるというのはあまりおすすめできません。着手しやすいのは「お客様や仕入先が絡まない申請事項」から段階的に取り掛かるのが良いでしょう。

代表的なのは「経費精算」です。経費精算はお金に関わる部分ではありますが、あくまで社内の中で完結する話で、何かあってもリカバーがしやすい部分です。またそれなりにボリュームがあり、手間や工数の圧縮実感が出やすい領域です。AI-OCRや写真を取るだけで申請できる仕組みを取り入れると、社外からの申請も可能となり、利便性を実感しやすい可能性が高いと言えます。

最終的にお客様に関係してきたり、金額が大きくなる、購買や契約申請などにも利用範囲を広げていくとよいでしょう。

まとめ

ワークフローシステムの導入で失敗する原因は、システムそのものよりも「現行運用をそのまま残そうとすること」にある場合が少なくありません。

もちろん、業務の特性上どうしても例外運用が必要なケースもあります。しかし、その例外を積み重ねていくと、システムは次第に複雑になり、追加開発や運用負荷の増大、さらにはシステムの外でExcelや紙による管理が始まるなど、本来目指していた業務効率化とは逆の方向へ進んでしまうことがあります。

ワークフローシステムの導入は、単に申請・承認を電子化するプロジェクトではありません。承認権限や組織体制、業務ルールを見直す絶好の機会でもあります。

そのため、

  • どこまで運用を標準化できるか
  • 例外運用を本当に残す必要があるのか
  • 個人ではなく役職に権限を持たせられるか

といった点を事前に整理しておくことが重要です。

システムに業務を無理やり合わせるのでも、業務にシステムを無理やり合わせるのでもありません。業務そのものを見直し、「標準化できる部分は標準化する」という視点を持つことが、ワークフローシステム導入を成功させる第一歩と言えるでしょう。