規程は十六冊ではなく一冊
承認限度額、代決の規則、エスカレーションを一度だけ定めれば、あらゆる伝票種別に効きます。モジュールごとに設定し直しません。
プラットフォームの能力 · 業務フロー
定めたとおりに動く、御社の手続き。
すべてのモジュールが共有する一つのフロー基盤です。ドラッグで流れを設計し、限度額と代決で承認し、どの段階にも証跡が残ります。
対象: 経営層 · 内部統制 · 部門長 · 導入チーム · 情報システム
これがもう一つのモジュールではない理由
業務フローは伝票を一つも持ちません。すべての伝票を動かすだけです。
休暇申請は人事のもの、購買依頼は購買のもの、契約は契約管理のものです。業務フローを別のモジュールに切り出せば、同じ様式を語る場所が二つになり、食い違った日にどちらが正しいか誰にも分かりません。ですからこれは十七番目のモジュールではなく、十六のモジュールが共に立つ土台です。
購買モジュール購買申請
- 下書き
- 承認待ち
- 承認済み
- 発注
フロー基盤
ポリシーゲート — 誰が、どの限度額で、何回、いつまでに承認するか
承認されれば、別のモジュールで待っていた仕事がそのまま開きます
伝票の状態遷移は、その伝票を持つモジュールが握ります。フロー基盤は判断が必要な一つの遷移だけに噛み合います。だから伝票を一つも持たず、モジュールと取り合うものもありません。
名簿ではなく組織図に従います
承認ルートは人事モジュールの役職と所属を読みます。担当者が部署を移ればルートも移るので、手続きを一つずつ直す必要がありません。
証跡は伝票と同じ場所に残ります
誰が起案し、誰がいつどの版をどの権限で承認したかが伝票そのものに残ります。監査の問いが来ても作り直す必要はありません。
一件の申請の一生
誰かが送信を押した瞬間から、突き合わせられる証跡が残るまで。
どの伝票にも同じ仕組みが働きます。下は購買申請が四つの段を通り、いま止まっている場所です。
実行中の申請PR-1042v2通った分岐 · 限度額を超える承認者待ち
購買申請
振り分け限度額を超える投資・緊急それ以外
経営会議限度額マトリクス順番どおりSLA 48h残り6時間
並行
財務部一人で足りるSLA 24h
部門長組織図に従う
両方の完了
直属上司組織図に従う
証跡
監査ログ
- 09:12申請者申請を提出
- 09:12フロー限度額で振り分け
- 11:04経理責任者追加見積を要求
- 01
起案
担当者が自社様式の電子様式に記入するか、条件に触れた瞬間に業務伝票そのものが申請を立ち上げます。
- 02
振り分け
ルールが金額・伝票種別・所属・限度額を読んで適切な承認者を選びます。複数の意見が要るときは並行で、順序が要るときは直列で進みます。
- 03
承認
承認者は業務空間でも携帯でも処理でき、補足を求めることも、不在時に代決を任せることもできます。期限を過ぎればSLAが上位へ引き上げます。
- 04
証跡
決定は完全な記録とともに元の伝票へ直接書き込まれ、次の業務段階が開きます。他システムへ手で書き写すことはありません。
この図は仕組みを読み取るための一例で、図中の数値は例示です。 限度額、承認段階、エスカレーションの時間は各組織の規程に合わせて設定し、導入の中で確定します。ソフトウェアは規程の運用を助けるもので、規程を置き換えるものではありません。
中身
ドラッグで設計し、実データの上で動かします。
設計と様式
- ノーコードのフロー設計画面上でドラッグして流れを組みます。段階、条件、分岐、繰り返しまで、コードは要りません。
- 電子様式自社様式の入力項目・検証・添付を、起案の段階にそのまま結び付けます。
- 版と試行稼働中の流れを下書きで直し、試してから公布します。進行中の申請は従来の版のまま進みます。
振り分けと承認
- 条件・限度額・代決金額や伝票種別や所属で分岐し、限度額を超えれば段階が自動で足され、不在時は代決者へ回ります。
- 並行承認と直列承認互いに依存しない部門は同時に意見を出し、後の段階が前の決定を見る必要があるときは順に進みます。
- SLAとエスカレーションどの段階にも期限があります。過ぎれば催促し、規程どおりに上位へ引き上げます。
証跡と運用
- 欠けのない記録すべての操作が人・時刻・伝票の版・理由を残します。二年後の監査の問いに答えるに足ります。
- 追跡とボトルネック申請がどこにあり、誰を待ち、どれだけ経ったかが見えます。よく詰まる段階は数字として現れます。
- すべてのモジュールの伝票の上で動きます同じ基盤が、休暇申請も購買依頼も契約も出庫伝票も修正仕訳も扱います。
エージェント層との境界
エージェントはフローの中で働きます。フローを置き換えません。
エージェントを備えた組織なら当然の問いです。AIが仕事をこなすなら手続きは何のためか。その手続きこそが、エージェントへの委任を安全にします。
誰が何をしてよいかはフローが決めます
エージェントは自分を呼んだアカウントの権限の中で動き、委任の範囲はフローそのものに宣言されます。手続きを迂回する近道はありません。
承認を要する仕事は今も人を通ります
エージェントは下書きを埋め、委任された分を書き込みます。その範囲を超えれば根拠付きの提案で止まり、承認の段階は承認の段階のまま残ります。
記録にはエージェントも残ります
どのエージェントが誰の委任で何をし、誰が承認したかが、人の操作と同じ台帳に残ります。
よくある質問
業務フロー層の境界。
これもモジュールですか？
いいえ、意図してそうしています。モジュールは一種類の業務記録を持ちますが、業務フロー層は何も持たず、他の十六のモジュールの記録を動かします。切り出せば同じ様式を説明する場所が二つできます。
デジタル行政の決裁ルートとは何が違いますか？
デジタル行政は伝票の一つの領域です。収発文書、印章、文書保存がそこに属します。業務フロー層はその領域と他のすべてが動く基盤です。文書の決裁ルートは、この基盤で組んだ具体的な流れの一つです。
プログラムを書けない人がフローを直せますか？
設計は画面上のドラッグなので、業務を知る人がコードなしで流れを組み、直せます。誰がどの流れを直せるかは権限の話で、導入の中で確定します。
一つの段階から外部システムを呼べますか？
段階からAPIで別のシステムを呼び、データを取得したり結果を渡したりできます。どのシステムを接続しどう認証するかは案件ごとに確定し、連携ページに対応するシステムの種類を掲げています。
詰まっている手続きを一つ、デモにお持ちください。
御社の実際の承認フローを一つお選びください。デモでは、今の限度額と承認段階のまま、それをサンプルデータの上に再現します。