考え方

構築前に、業務の工程を設計します。

受注や請求が確定する前にも、仕事は動いています。見積前、手配待ち、承認待ち、差戻し、AI判定後の確認まで設計すると、人、モノ、外部先、AI処理を業務の中で進められます。

基幹業務

作る前に、外せない工程を決めます

便利な機能を足す前に、どの工程で止まり、誰が何を待ち、どの条件が揃うと次へ進むのかを扱います。

前提今ある仕組みを前提にする

業界システム、SaaS、Excel、メール、紙を一度否定せず、活かす範囲と作る範囲を分けます。

分析時間がかかる受け渡しを特定する

見積前、手配待ち、承認待ち、差戻し、請求前確認など、担当者の確認に時間がかかる箇所を特定します。

実行小さく作り、すぐ直す

制度、現場、社外先、請求条件が絡む業務でも、現場テストで違和感を戻せる形にします。

比較

確定した情報を残すだけでなく、確定する前の情報を持つことで、次に動かす相手、モノ、外部先、AI処理が見えてきます。

製品・SaaS

Microsoft 365、Power Automate、kintone、Salesforce、Dynamics 365、ServiceNow などは有力な選択肢です。ただし、先に決めるべきなのは製品名ではなく、どの工程を残し、つなぎ、作り替えるかです。

Microsoft

申請、通知、承認、ファイル管理、Teams通知を既存のMicrosoft環境に寄せて構築できる場合は、独自開発よりも運用定着を優先します。

Power AutomateSharePointTeamsExcelMicrosoft 365

Low-Code

申請・承認・台帳・ステータス管理が中心の場合は、kintoneやPower Appsを残す選択肢も確認します。足りない部分だけ外部連携や独自画面で補います。

kintonePower Appsプロセス管理通知連携

CRM / Field

顧客、案件、作業指示、現場担当、スケジュール、請求前確認が絡む場合は、Field Service系の考え方を参考に業務単位を設計します。

Salesforce Field ServiceDynamics 365 Field ServiceServiceNow FSM

作り替え方

現在の状況に合わせて、構築前に扱うテーマを分けています。

次の一歩

業種名や製品名ではなく、確認待ち、手配中、承認待ち、請求前確認など、実際に時間がかかっている工程をもとに最初の着手範囲を決めます。