JASTPRO DXの道 第8話「事務所内DXチャレンジ(前編)」
【初出:月刊JASTPRO 2022年8月号(第519号)】
羅針盤
ここまで3回、当協会DXの本丸と位置付けていたコード管理システム刷新について紹介してきました。今回からは、その本丸を支える裏方、当協会事務所におけるDXへの具体的な取り組みについて触れていきます。
まず本連載の第4話を振り返ってみますと、本年度のチャレンジとして「事務局内部においては、徹底した電子化を推し進めていきます」と決意表明がされておりました。その具体的手法としては、以下のように書かれています。
(1)現在紙やファイルで運用している台帳類の管理や書面発行プロセスを、すべて電子化
(2)事業に役立つ職員向けデータベースや FAQ などのリファレンス、また事業関係者とのコミュニケーションを効率化するツールを構築し、知識共有と業務効率を強化
(3)これまで手薄だったデータ活用も始めていくことで、貿易簡易化に役立つ調査・研究に役立つだけでなく、コードの価値向上に向けた取組みを開始
さらに、これを進めるためのツールについても「こういった取組みにおいては可能な限り共通の、または連携が可能なシステム開発プラットフォームを採用します。(中略)当初から内製を主体として変化に強いシステムとして構築していきたい」との言及があります。具体案から利用する道具まで、実に明確。実現できれば、当協会事業のデジタル変革に大きく寄与することは確実。筆者も100%賛成です。そこで、これらを羅針盤として進めていくことにします。
「紙多すぎ」問題
今回は、このうち「現在紙やファイルで運用している台帳類の管理や書面発行プロセスもすべて電子化」という案を中心に、その取り組み状況をご紹介していきます。
筆者が入職した2021年10月、当時の事務所内手続きを振り返ってみると、確かにほぼ全て紙ベースで行われていました。社内でよく使う稟議・決裁書類や経費申請、休暇申請、手書き領収証の発行などなど・・・いったいいつ原版が作られたのだろうという古い書式による申請書がそこかしこに点在しているような状態。
これはつまり、何か申請するために過去の申請書を確認したり、申請をもとに事務処理をこなしたり集計したりするような仕事にとても手間がかかる上に、紙によって仕事をする限り事務所でしか仕事ができず、担当者は全然テレワークできない状況であったということになります。そこで、総務企画室(当時は庶務室)のメンバーと相談して、まずはこの「紙多すぎ」問題を解決する方法を探ることにしました。
紙書類の電子化。最初の一歩としてはパソコン、もう少し具体的にはワープロソフトや表計算ソフト、データベースソフトを使って電子化するというのが取り組みやすいやり方です。
最初の一歩、でも・・・
ただ、最初の一歩ではありますが、このやり方には大きな問題があります。書類自体を電子データにするのは良いですが、そこで終わってしまうと中途半端なことになってしまいます。例えば決裁プロセスにおいて、
「ワープロソフトや表計算ソフトで申請書を作る」→「印刷して紙で回覧」→「決裁にはサインかハンコ」→「決裁後、結果をパソコンに打ち込む」・・・
このように、物理的な作業が残ってしまうわけです。そこで、帳票のフォーマットを定めるだけでなく、入力自体もパソコン上で行い、データを事務所内のファイルサーバーなどで共有するという方法を考えます。しかし、「フォルダが深くなりすぎてどこに書式があるのかわからない」「帳票フォーム、変更してはいけない箇所を変更しちゃった」「間違えて前の書類を上書きしちゃった」、果ては「うっかり消しちゃった」・・・などなど、ファイルサーバーを使った電子書類の活用には古くから存在しながらもなかなか解決できない問題が起きがち。アクセス権限を細かく決めてしまうという方法もありますが、これはこれで運用が煩雑になる傾向があり、あまり現実的ではありません。
他にも、VPN接続環境(事務所外と事務所内を安全に接続する方法)を整えるなどの準備をきちんと行わないと、事務所の外からファイルサーバーのデータにアクセスすることができず、リモートワークの実施にも支障が出てしまいます。
こういった事情から、今回はファイルサーバーを中心とした電子化ではなく、もっと根本的なところから取り組んでいくことにしました。
電子化はプロセス丸ごと
根本的なところ。それは、電子化する場合には「プロセスを含めた仕組みそのもの」、つまり最初から最後まで一貫性のあるプロセス設計と、それを実現できる仕組みまで用意する必要があるということです。決裁プロセスで言えば「電子的に文書を作成して、オンラインで共有・回覧、ハンコに代わる承認が出来て、その証跡をきちんと残せる」ようにするということです。もちろん、この過程で決裁の種類や回数を出来る限り減らし、またそもそも必要ない決裁であれば手続き自体をなくしてしまうといった業務そのものの見直しが行えるとなお良し。そして、前述の問題点を考慮すると、「きちんとアクセス権限が管理できること」「事務所内だけではなく事務所外からもアクセスして処理ができること」という要件も見えてきました。
ありがたいことに、現代においてはこういった要件を満たす仕組みが「クラウド型ワークフローシステム」というカテゴリで容易に導入できるようになっています。当協会でも、書式や決裁プロセスを職員自身で設計・実装できる比較的安価なツールを選定し、これまで紙で行ってきた申請プロセスをほぼ全て電子化することに成功しました。
新しい決裁プロセスを作りたい場合も自力ですべて実装できますし、既存のプロセスや書式に変更があった場合も即時に変更してアップデートできるため、「あ、この申請書古いよ、こっちの新しいやつを使ってって言ったでしょ??」「あれそうだっけ、じゃあ作り直しか・・・とほほ」というような悲しいやり取りもなくすことができました。
他の仕組みは?
それでは、他の仕組みはどうでしょう。例えば、本連載の第3話でご紹介した、海上コンテナに搭載する危険物の申告とコンテナ以外のバラ詰み貨物の危険物申告の際に使用する「危険物明細書標準書式用紙」の販売に係る手続きを当協会ホームページ上で行えるようにした、という事例です。ホームページを通じたオンラインでの注文を実現し、複数の職員で注文の情報共有ができるようになり、速やかな入金確認も可能になるなど、お客様にも当協会にもメリットのある取り組みでした。
この考え方を推し進め、当協会に対する注文処理だけでなく、その後に発行する領収証や印刷物の発送ラベル作成まで一気通貫に行える仕組みを整えればもっと効率的に業務処理を進められそうです。例えばホームページの書式注文フォームと当協会の受付システム、その後の注文を処理する仕組みまでを連携する形で構築すれば実現できる気がします。まだ具体的なシステムづくりには至っておりませんが、これ以外の業務にも応用できそうなので、何らかのシステム開発ツールを活用して取り組んでみる価値がありそうです。
ツール選びの肝
ここで肝となるのが、「システム間の連携」です。ひとつのシステムで全ての業務をカバーすることは(不可能ではないかもしれませんが)難しく、またコストや利便性の面でも現実的ではありません。餅は餅屋。各システムの強いところを上手に組み合わせ、システム間でデータを連携して・・・言うは易く行うは難しなのですが、少なくともシステム開発ツールを選ぶ段階で、そういった連携が出来るとアピールしているものを選んでおく必要があるということです。
もう一つ大事なのは、システムを素早く作り、まずは使ってみること。その後必要に応じて協会内部で修正できるようにしておくことです。システムを変更しようとするたびに開発業者と相談して見積もりを取ってプログラムしてテストをして・・・というプロセスは、前回までに紹介したコード管理システムのようにある程度規模の大きな、かつ業務の仕組みがそれなりに整っているシステムを構築する際には有効ですが、今回の取り組みのように小規模な事務所で試行錯誤を繰り返しながらデジタル化を目指そうとする場合には時間も手間もかかりすぎてしまいがち。
そのため、先に紹介したワークフローシステムのように、自分たちである程度内製できるような仕組みであることが望ましく、これもまたプラットフォーム選びにおける条件の一つとなります。今流行りの表現を借りれば「ノーコード/ローコード(プログラミング不要、あるいは最小限のプログラミングで実装可能な)プラットフォーム」を採用しましょう、ということになります。
このような考え方に基づき、「システム間連携が出来る」「ノーコード/ローコードプラットフォーム」をいくつか検討した結果、とある国産ツールを選定しました。これを利用して、各種台帳類の電子化や職員用のデータベース、さらには他システムとの連携を進めていきます。次回は、その取り組みについて詳しく紹介していきます。(つづく)
この記事が気に入ったらサポートをしてみませんか?