2.3 受注決裁フローのシステム化を行うDX : 業務とシステムの関連性
企業活動のひとつの重要な業務は「営業」ですが、営業活動の中でよくあるのが顧客との交渉の中で値引きを行うことです。ある金額の範囲内であれば、現場の営業に値引きして販売することがあらかじめ許容されている場合もありますが、値引きして販売 (受注) するためには、社内での承認を得る必要があることも一般的です。また、この「社内での承認」は販売管理部門や経理、事業部長など複数の人間・部署の承認を必要とすることも多く「受注決裁フロー」と呼んだりします。
受注決裁フローという業務は多くの企業で行っている一般的な業務のため、NOTESあるいはサイボウズなどのさまざまなグループウェアを利用するだけでも、シンプルなワークフローであれば実現できますし、HubSpotのようなMAツールなどでも対応可能です。
しかし、受注決裁フロー上で経理・事業部長などが判断するための情報としては、
・申請してきた値引き金額でどれだけの営業利益が残るのか
・当該顧客からのこれまでの受注実績や今後の受注見込み
(今回値引きして受注すると今後のプラス効果がどれだけあるか)
などさまざまな情報が必要となります。受注決裁フローを紙からシステム化するにあたり、判断材料となる営業利益や受注実績なども決裁者の画面に表示できるようにするDX化案件を考えてみたいと思います。
a. 必要とされる業務理解
このような複数の関係者に業務を流していくITシステムは「ワークフロー」といいます。上述のようなすこし複雑なワークフローを実現しようとする場合には、「どのようなフローを実現する必要があるか」「どのような情報を画面上に提示する必要があるか」の二点に注意が必要です。
どのようなフローを実現する必要があるか
ワークフローであれば、各承認者が「承認するか」「承認しないか」というふたつの選択肢は最低限でも指定できる必要がありますが、フローを複雑にする下記のようなバリエーションを求められる場合があります。
・承認はしないが、単純な否認ではなく、ワークフロー上の何ステップか手前まで戻す
・受注決裁申請内容 (値引き幅等) により、ワークフローを変化させる (承認者が増減)
・受注決裁申請内容 (取扱商品等) により、ワークフローを変化させる (承認者が変化)
・ワークフロー経路上のユーザの権限によって表示内容や入力可/不可を変化させる
どのような情報を画面上に提示する必要があるか
営業担当が申請時に入力/添付する情報を、決裁者の画面上に表示することはもちろんできる必要がありますが、決裁判断するための参考情報として、外部から情報を取り込んで下記のような情報を画面上に表示できるようにすることを求められる場合があります。
・(申請内容の値引きをした場合の) 営業利益 (あるいは原価金額)
・当該顧客に対するこれまでの販売実績 (取引実績)
また、場合によっては、上記の情報 (原価金額など)を申請者の営業担当には見えない状態にすることを求められる場合もあります。情報管理 / セキュリティも実現するシステム構成に影響を与える一面となり得るので注意が必要となります。
b. 必要とされるシステム知識
受注決裁フローのシステム化ということであれば、ワークフロー機能のシステム構築ということになりますが、ワークフロー機能は一般的にほかの業務に付随する機能です。
ある業務を遂行してよいかどうかを事前に承認を得る行為としてワークフロー機能が求められることが多く、承認を得る対象の業務システムにワークフロー機能も用意されていることが多くなっているのだと思います。
従って、ワークフローを実現するシステムを検討する第一歩としては、元の業務システムに付随するワークフロー機能を用いるのか、ワークフロー部分を別のシステムで実現するのかという検討を行うことが多くなるかと思います。
もちろん、元の業務システムで実現できればそれでよいのですが、機能面等で充足できない場合には、ワークフロー機能は別のシステムで実現することになります。基本的なワークフロー機能であれば、さまざまなツール/サービスに機能として含まれています。各種グループウェアをはじめERPやMAツールにも含まれていますし、ワークフロー構築用のサービスもあります。
ワークフローの機能面での比較ポイントとなるのは下記のような機能です。
・入力フォームのカスタマイズ性
・複雑な承認ルートが設定できるか、閲覧権限のコントロール
・監査対応・ログ機能
・外部連携・データの処理機能
また、ワークフロー構築用のサービス/ツールと似ていて少し異なるジャンルとしてBPM (Business Process Management) があります。BPMツールとしては、たとえばQuestetraなどのツール/サービスがあります。BPMは基本的に業務プロセスのシステム化を実現するためのサービス/ツールで、承認ワークフローというのもひとつの業務なのでBPMでも実現できます。複雑/高機能なワークフローを実現しようとする場合には、BPMのサービス/ツールを利用するのも選択肢となると思います。
c. 本タイプ案件における業務とシステムの両面からのWeb構築
受注決裁フローのシステム化ということなので、営業がSFAをすでに利用している場合には、そのSFAでワークフローを実現できないかを検討するのが第一のポイントとなります。
SFAは利用しているものの、そのSFAでは実現できない場合には、SFAとワークフローのシステムを連携させて実現することになります。受注決裁フローの申請内容には、当該案件の内容(顧客情報、案件情報)を含める必要がありますが、そのような情報の多くはSFAに入力されていることが多いので、SFAに登録済の情報はワークフローのシステムに連携して、再度入力する必要がないシステムとすることが求められます。
基本的には、各種SFAもワークフロー構築用のサービス/ツールなども外部連携のためのAPIを用意しているのが一般的となっていますので、それらのAPIを呼んでシステム連携を実現するアプリケーション開発を行えば一般的にデータ連携は実現可能です。また、SalesforceやHubSpotのような多くの人たちに利用されているサービスでは、外部連携用のアプリがいろいろ用意されている場合もあります。そのようなアプリがすでにあるのであれば、システム開発をする必要もなくSFAとワークフローとの連携を実現することができます。
もし、そのようなアプリが存在しなかったり、一部の情報はすでにSFAに入っているものの、受注決裁フローの申請内容としてはさらに追加で情報を入力してもらう必要があるような場合には、外部にWebフォームを開発するのもひとつの選択肢となります。Webフォームから受注決裁の申請をしてもらうわけですが、そのWebフォームを開いたタイミングで、そのWebフォームアプリケーションがSFAのAPIを呼ぶことによりSFAに入力済の情報を取得して、すでに入力済の状態でフォーム画面を表示した上で、申請にあたっての追加の情報を営業担当に入力してもらい、申請処理としてWebフォームアプリケーションがワークフローのシステムのAPIを呼ぶことにより、ワークフロープロセスを起動する構成とすることが考えられます。
Webディレクタとして次のステップをさがしている方たちへ
これからのWeb構築・Webディレクションとして、業務にまで踏み込んでディレクション/プロデュースすること、それが近年のバズワードであるDXにもつながること、そしてWebの進化とともにWeb構築の各種ツール/サービスやSaaSが広がってきていることにしたがって、業務とシステムの両面からWeb構築・運用していく人間が求められていくこと、そのためにどのような知識や能力を身に着けていくとよいかについて解説している「マガジン」です。