Kliv

    このページは英語から翻訳されています。

    ビジネスツール

    承認ワークフローシステムを構築する

    金額とカテゴリで自動ルーティングされる申請。休暇の週を引き継げる承認者。監査人のために復元するのではなく、データベースが書く監査証跡。

    kliv.dev

    テキスト ボックスにアイデアを入力するだけで、AIがそれを構築します。

    94 文字

    承認フローはメールで死ぬ

    120人の部品メーカーでは、購買申請は金額、原価部門、見積書を持つ事実です。多くの会社では、それは同時にメールでもあります。転送され、件名の下に埋まり、3月に監査人がスピンドルを誰が承認したか聞いたとき、誰も見つけられない返信で承認されています。

    借りられるワークフローツールはステップと担当者を知っています。でもあなたのしきい値、カテゴリ、保全予算が11月に閉じることは知りません。Klivは、あなたが所有するデータベース内で、実際のルールを中心に承認システムを構築します。ルーティング、判断、証跡は監査人に示せる場所にあります。

    監査人が求める記録

    承認システムの価値は、後で何を証明できるかです。これらを証明します。

    全部入りの申請

    申請は品目、金額、原価部門、仕入先の見積書を持ちます。見積書は根拠となる行に添付された、ファイルストア内のPDFです。

    ルーティングルール

    100,000円未満は上長。100,000円から1,000,000円は部門長。それを超えたら財務と拠点長の両方。申請を回したルールは、ルール変更後も申請と一緒に保存されます。

    時刻付き判断

    承認、却下、詳細差し戻し。それぞれが行で、実行者と時計を持ちます。履歴は一度書かれ、編集されません。

    委任

    7月の2週間、部門長はキューを代理へ渡します。開始日、終了日、本人の代理として行われたすべての判断への印付きです。

    誰が何を見るか

    申請者は自分の申請を見ます。承認者は自分のキューを見ます。財務はすべてを見ます。これは画面のタブではなく、データベースの行レベルセキュリティです。

    1つの購買申請の48時間

    2号ラインのスピンドルが摩耗しています。申請がどう動くか見てください。

    01

    月曜09時12分、申請

    機械工が800,000円の交換スピンドルを必要とします。品目、原価部門、見積書添付。現場端末で30秒です。

    02

    月曜09時12分、ルーティング

    800,000円はしきい値の間にあります。部門長、次に財務。チェーンはルールで選ばれ、申請と一緒に記録されます。

    03

    月曜14時03分、Slackから承認

    部門長は承認チャンネルで申請を見て、その場で処理します。アプリが投稿し、彼女の操作に反応します。

    04

    火曜08時30分、委任が拾う

    財務責任者は休暇中です。今週は代理がキューを持っています。続く承認には、委任下で行われた印が付きます。

    05

    火曜10時40分、完了し証明可能

    申請者へメールが届き、発注番号が発行されます。ルール、実行者、時計を含む全チェーンが、3月に監査人が読む1つの記録です。

    ルールを一文にする

    kliv.dev

    購買承認

    金額しきい値、原価部門、添付見積書。

    “金額しきい値、原価部門、見積書添付、部門別支出の月次レポートを持つ購買承認ワークフローを作りたい。”

    kliv.dev

    経費承認

    領収書写真を入れ、承認済み台帳を出す。

    “スタッフが領収書を撮影し、マネージャーがキューから承認し、財務が承認済み経費を月次台帳へエクスポートできる経費承認アプリを作りたい。”

    kliv.dev

    図面リリース管理

    公開前に設計と品質が承認。

    “図面がリリース版になる前に設計と品質の承認を必要とし、古い版は読み取り専用で保持するエンジニアリング文書リリースワークフローを作りたい。”

    どう組み上がるか

    ルールはあなたのもので、変えられます。 しきい値、カテゴリ、チェーンは編集できるデータです。方針そのものの形が変わるとき、「設備投資4,000,000円超はCFOが必要になった」と会話で伝えれば、Klivがスキーマとルーティングを移行します。

    Slackは表面であり、コピーではありません。 アプリは保留中の各申請を承認チャンネルへ投稿し、そこで起きたことに反応します。接続の認証情報はコードではなく保管庫にあります。承認者はすでにいる場所で処理し、データベースが唯一の正本のままです。

    見回らなくてよい自己承認禁止。 テストは構築と一緒に届きます。下には実際のVitestがあります。依頼すれば、Scenario(Klivの検証用シナリオ)が自分の800,000円申請を承認しようとする申請者を演じます。試行は拒否され、実行は理由を正確に示すレシートを残します。ルールはメモではありません。合格するテストです。

    サイクルタイムは感覚ではなく測定です。 承認者ごとの判断時間、詳細差し戻し、原価部門別支出。一文で定義する分析で、タグマネージャーは不要です。

    承認フローを作ったチームは、たいていバックオフィスの残りも欲しくなります。社内ツールのソリューションがその流れを追っています。

    監査人が聞くこと

    履歴は後から編集できますか?

    できません。判断は実行者と時刻を持つ追記専用の行です。訂正は古い判断を参照する新しい判断であり、編集ではありません。監査人が読むものは、起きたことです。

    承認者が退職または不在の場合は?

    委任は開始日と終了日を持つ第一級の記録で、退職時はキューを再割り当てします。委任下で行われた判断は、永続的にそう示されます。

    ルール変更は進行中の申請に影響しますか?

    あなたの判断次第です。ただし既定では、申請は回されたときのチェーンを保ち、そのルール版が一緒に保存されます。黙って再ルーティングされません。

    承認者はどうサインインしますか?

    アプリ自身のアカウントでサインインします。メールとパスワード、Googleサインイン、パスキー、必要なら二要素認証。さらに、誰が承認し、誰が申請だけできるかを決めるロールがあります。

    転送で承認するのをやめる

    新入社員に説明するように、しきい値とチェーンを書き出してください。その説明が構築プロンプトです。