HITOWA、SmartDBでグループ共通の申請基盤を構築

〜旧ワークフローのサポート終了を機に、単純移行にとどまらない業務改革へ〜

SmartDB導入以前は、十数年利用してきたワークフローを使っていました。しかし、グループ規模の拡大に伴い機能不足が目立ち、刷新が必要になりました。会社ごとに申請アプリを個別に運用していた結果、似たアプリが増えて保守が難しくなっていました。

さらに、旧ワークフローで巻き取れない紙業務が残り、「転記」などの手作業も発生していました。管理者アカウントでしか業務アプリを開発できず、デジタル化が進みにくい状況でしたね。また、旧ワークフローはクライアントサーバー型で、連携やデータベース機能が弱く、グループ全体での活用には限界がありました。

決裁内容ごとに申請が分かれていたことに加え、会社の統廃合に伴って証跡保管を目的として残していた申請アプリもあり、結果として全体数が増えていきました。

なかでも課題が多かった稟議は、契約に関する稟議、支出に関する稟議、方針などその他の稟議といった大きく3カテゴリーに分かれていた時代もあり、さらに申請項目ごとに細分化されて広がっていきました。グループ会社の新設なども重なり、結果として稟議フォーマットが51種類に増え、申請者が「どれを使うべきか」迷う状態になっていました。

当時は業務アプリを横断して検索する機能がなかったため、申請者は使うべきアプリを探す際、1つずつアプリを開いて内容を確認して、「同じようなのが出ている。これだ」と判断する探し方をしていました。申請書の作成以前に、申請書を探す行為に時間を費やしていたと思います。

また、運用や保守は、ほぼ私ひとりで対応していました。同じような申請でも各社限定のものが多く、グループとして同一のフォーマット、同一のバインダーで管理できればいいのに、という思いがありました。

検討は、総務部と情報システム部が連携して進めました。5〜6製品を比較し、権限制御要件を満たしたのは4製品程度です。残りは要件未達のため、候補から外れました。最終的な決め手は費用面でした。ただし「費用の前に」最低条件として、グループ横断で利用することが前提だったため、申請者側の閲覧権限を制御できることを強く重視していました。

単に申請業務をデジタル化するだけでなく、台帳管理やデータ連携が行える点も含め、基盤としての価値が意識されていました。

具体的には、API連携の実現性、クラウドであること、SAMLによるSSO対応です。他製品ではAPI利用に上位ライセンスが必要で、全員を上位にすると費用面で見合わない、といった話がありました。実運用上の連携頻度は業務によって異なりますが、朝1回、4時間に1回、15分に1回、場合によっては5分に1回の頻度で自動連携することを想定していました。

導入後、ワークフローの中で最も懸念していたのは稟議でした。稟議の要件が一番複雑だったため、まず稟議から着手し、そこから広げて稟議に紐づく支払、契約などへ順次展開していった形です。

大きな方針は「申請者が混乱しないこと」です。旧ワークフローからSmartDBへ移行する際、申請者側の見え方や操作感が急に変わると混乱が大きいため、最初は旧システムに近い見え方に寄せました。そのうえで、SmartDBの機能（表示制御など）を活用し、「入力に必要な部分だけを見せる」設計にしつつ、段階的に変化を加えました。

旧ワークフローでは稟議フォーマットが51種類に増えたとお伝えしましたが、SmartDBは一つの稟議申請アプリで完結しています。

そうですね。そのほかに「苦労した点」の中核は、承認者ルートの最終判断などの運用を総務側の手作業から、申請者がルート選択し自動的に承認者が決まる設計に変更したことです。

HITOWAはひとつの拠点でも複数のカンパニーが同居していたりするので、所属拠点やカンパニーごとの職務権限規定を考慮すると承認ルートが複雑になります。

そのため承認者設定を自動化するためのマスタを用意し、稟議区分などの選択により承認者が変わるようにしました。SmartDB上のアカウント情報には、部門コードや役職コードなどの拡張情報を付与できるので、そちらを活用しています。

以前は、グループ全体で約800施設から稟議が起案されるため、総務側の負担が大きくなっていました。申請者に承認ルートを選択させることで、総務側は「申請内容のチェック」などに注力できるようになり、そのほかの作業負荷を減らしました。

基本的には旧ワークフローで起案・決裁された約75,000件の過去データをすべてSmartDBに移行しています。手順としては、旧ワークフローから文書データをCSVで出力してPDF化、また添付ファイルなどがある場合はダウンロードして、文書データと添付ファイルを1セットでSmartDBに移行した形です。

そうですね。旧ワークフローからの出力は手作業だったので時間がかかりましたね。複数件を対象に一括で操作することはできたものの、回数を分けて実施していました。一方で、SmartDBへの登録はAPI経由で行えましたので、ほとんど苦労なく進められたと思います。

はい。本番稼働しているアプリは100個前後で、バックオフィス業務を中心に利用しています。 単体のアプリで完結させるというより、バックオフィス全体の流れに合わせてアプリを連携していて、前工程で登録した情報を後続の申請などで利用できるようにしています。 グループ各社で個別にExcel管理していたマスタ類も、SmartDBで整備していくことで、表記揺れの確認などのムダも減らせるようになってきました。

いくつかありますが、たとえば契約管理を起点に、物件管理に連動させています。物件管理業務は、契約管理に紐づく物件（賃貸借・リース品・車両など）を整理する業務でして、新リース会計基準に向けて、契約情報とそこに紐づく「モノ」の情報をきちんと管理しようという背景があります。 契約管理アプリを親にして、その下に物件をブランチ部品（※）で紐づけているので、契約管理アプリでの承認が完了すると物件管理側にも必要な情報が自動作成されます。

そうですね。代表的なのが支払依頼です。 支払依頼はグループ全体で利用していて、会計システムの勘定奉行とも連携しています。完全に直接つないでいるというより、SmartDBから出力したデータを加工ツールに通して取り込む運用ですね。支払依頼は、稟議（決裁）の申請情報と紐づけています。 SmartDB上で「この支払はどの稟議で承認されたものか」を選べるようにしていて、決裁済みのエビデンスも添付したうえで、支払依頼につなげる形です。承認プロセスと実務処理を、一本の流れとして扱えるようになりました。

まさにそこが次のポイントで、法人マスタの整備ですね。 もともと取引先マスタ自体はあったのですが、支払先ベースで管理していたので、同じ法人でも事業所が違うと別管理になりがちで、名寄せができていませんでした。 インボイス制度や電子帳簿保存法への対応も背景にあって、法人単位で情報を管理する必要がある、という話になりました。法人マスタを整備して、そこに支払先や契約情報を紐づけることで、グループ横断で取引関係を把握しやすくしています。結果として、グループ各社がExcelで持っている情報も混ざって、社名の表記揺れの確認など、総務側にムダな業務が発生していました。

外部の法人データベースとAPI連携しています。法人番号を入れると情報が自動補完されるので、入力負荷と表記揺れを抑えやすいです。 まだ精度を上げないといけない部分はありますが、グループ全体で「この法人とはどういう取引があるか」が一発で見える状態を目指しています。リスク管理や与信の観点でも効いてくるので、総務や法務なども含めて関わってくる話だと思います。今後は、電子契約の領域も、さらに一気通貫にしていきたいです。具体的にはGMOサインと連携して、申請から契約締結、保管までをつなげていく構想です。

一番多いのは、やはり「操作しやすくなった」「画面が見やすくなった」という声ですね。旧ワークフローは画面デザインも古く、使い勝手の面でストレスがあったのですが、SmartDBに移行してそこが改善しました。また業務の進め方についても、以前は申請がデータとして扱いにくくて「あの時の申請はどうなっていたか」を探すのが大変でした。SmartDBだと申請情報がデータとして残るので、検索して振り返ったり、状況の確認が進めやすい状況のようです。

そうですね。申請アプリ自体を整理したこともあって、「どこから申請すればいいか分からない」が減りました。 それに加えて、フォーム上で選択肢やマスタを整備しているので、以前のように「何を書けばいいか分からない」ではなく、「これを選べばいいんだな」という直感的な入力に近づいています。最近では総務に限らず、財務など他部署からも「紙や直接のやり取りで回していた申請を、SmartDB側に寄せたい」という相談が増えました。便利さが社内に浸透してきた感覚があります。

業務系システムの相談が直接来るケースがあります。Excelやスプレッドシートで管理している業務を見直すタイミングで、選択肢の一つとしてSmartDBを提案することも出てきました。 単に申請を電子化するだけでなく、申請情報をデータとして残して連携できるので、業務改善の議論もしやすいですね。