דף זה תורגם מאנגלית.
כלים עסקיים
בניית מערכת לניהול תהליכי אישור
Kliv הוא בנאי אפליקציות מבוסס בינה מלאכותית. תארו את כללי ניהול תהליכי האישור שלכם - ספים, ניתוב, האצלות, אישורי Slack, דוחות, ותיעוד ביקורת - וזה בונה את האפליקציה.
פשוט הזן את הרעיון שלך בתיבת הטקסט ו-AI יבנה אותו עבורך
מה זה Kliv?
Kliv הוא לא מוצר לניהול תהליכים עם שלבים קבועים - זו בינה מלאכותית שבונה עבורכם תוכנה.
אתם מתארים במילים פשוטות את האפליקציה שאתם צריכים, ו-Kliv בונה את מסד הנתונים, הלוגיקה, המסכים, האינטגרציות והכללים. התוצאה שייכת לכם, היא רצה בחשבונות שלכם, ותוכלו לשנות אותה בהמשך פשוט על ידי בקשה. זו לא תבנית מהמדף.
בעמוד הזה, האפליקציה הזו היא מערכת לניהול תהליכי אישור. Kliv בונה כל מיני סוגי אפליקציות ווב; זו מנתבת בקשות, מתעדת החלטות, מטפלת בהאצלות, ושומרת תיעוד ביקורת.
למה תהליכי אישור מתים באימייל
לבקשת רכש יש סכום, מרכז עלות, הצעת מחיר, וכלל לגבי מי חייב לאשר אותה. בהרבה חברות זה הופך לשרשור אימיילים, וקשה להוכיח את ההחלטה מאוחר יותר.
Kliv בונה את מערכת האישורים סביב הכללים שלכם. בקשות, ניתוב, החלטות, האצלות ודוחות חיים במסד נתונים ששייך לכם, כך שהתשובה לשאלה „מי אישר את זה?” היא רשומה, לא חיפוש באימייל.
הרשומות שמבקר חשבונות היה מבקש
מערכת אישורים צריכה להוכיח מה קרה מאוחר יותר. הרשומות האלה עושות את זה.
בקשות
כל בקשה נושאת פריט, סכום, מרכז עלות, וצירוף הצעת מחיר במאגר הקבצים.
כללי ניתוב
מתחת ל-2,000 ₪, המפקח. בין 2,000 ל-20,000 ₪, מנהל המחלקה. מעל לכך, כספים ומנהל האתר. גרסת הכלל שניתבה את הבקשה נשארת איתה.
החלטות
החלטות של אישור, דחייה, והחזרה לפרטים נוספים הן שורות עם גורם מבצע וחותמת זמן.
האצלות
מאשר יכול למסור תור לטווח תאריכים מוגדר. החלטות שהתקבלו במסגרת האצלה מסומנות ככאלה לצמיתות.
נראות
מבקשים רואים את הבקשות שלהם, מאשרים רואים את התורים שלהם, וכספים רואה הכל. הגישה נאכפת על ידי כללי שורה.
לדוגמה: יצרן החלקים של מיכל
כך יצרן אחד יכול להשתמש במערכת אישורים שנבנתה עם Kliv. זו רק דוגמה - אתם תתארו את הספים, הקטגוריות, כללי ההאצלה, וצורכי הביקורת שלכם.
בקשת רכש מתחילה עם העובדות הנדרשות
מכונאי מבקש ציר בשווי 14,000 ₪, מוסיף את מרכז העלות, ומצרף את הצעת המחיר של הספק מהמסוף בקומת הייצור.
הסכום בוחר את הניתוב
14,000 ₪ נמצא בין הספים, כך שהבקשה מנותבת למנהל המחלקה ולאחר מכן לכספים. שרשרת הניתוב שנבחרה נשמרת עם הבקשה.
המאשר פועל מתוך Slack
מנהל המחלקה רואה את הבקשה בערוץ האישורים ומאשר אותה שם. האפליקציה מתעדת את ההחלטה חזרה על הבקשה.
האצלה מכסה את חופשת הבקר הכספי
הבקר הכספי נמצא בחופשה, כך שהסגן שלו מחזיק את התור במשך השבוע. האישור מסומן כמי שניתן במסגרת האצלה.
הבקשה נסגרת עם מסלול הניתן להוכחה
המבקש מקבל אימייל, מספר הזמנת הרכש מונפק, והכללים, הגורמים המבצעים, חותמות הזמן, והצעת המחיר - כולם ברשומה אחת.
תארו את כללי האישור שתרצו
Kliv בונה מהתיאור שלכם, אז כללו סכומים, קטגוריות, מאשרים, האצלה, צירופים, התראות, ודוחות. ככל שתתנו יותר פרטים, הגרסה הראשונה תהיה קרובה יותר.
אישורי רכש
ספי סכומים, מרכזי עלות, והצעות מחיר מצורפות.
“בנו תהליך אישור רכש. בקשות מתחת ל-2,000 ₪ עוברות למפקח, 2,000 עד 20,000 ₪ עוברות למנהל המחלקה, וכל דבר מעל 20,000 ₪ עובר לכספים ולמנהל האתר. דרשו צירוף הצעות מחיר, עקבו אחר מרכזי עלות, תמכו בהאצלה בזמן חופשה, ושלחו באימייל דוח הוצאות חודשי לפי מחלקה.”
אישור הוצאות
צילומי קבלות, תורי מנהלים, וייצוא לכספים.
“בנו אפליקציית אישור הוצאות שבה עובדים מצלמים קבלות, מנהלים מאשרים מתוך תור, הוצאות מעל 4,000 ₪ דורשות גם אישור כספים, והוצאות מאושרות מיוצאות לפנקס חודשי עם עובד, קטגוריה, מע"מ, וקישור לקבלה.”
בקרת שחרור שרטוטים
אישור תכנון ואיכות לפני שחרור.
“בנו תהליך שחרור מסמכי הנדסה שבו כל שרטוט דורש אישור תכנון ואיכות לפני שהוא הופך לגרסה המשוחררת. שמרו על גרסאות ישנות לקריאה בלבד, תעדו מי אישר כל מעבר, והודיעו ב-Slack כשמשחררים שרטוט.”
איך זה מתחבר יחד
כללים יכולים להשתנות. ספים, קטגוריות, ושרשראות אישור הם נתונים שאתם עורכים. אם המדיניות משתנה, תוכלו לתאר את השינוי ו-Kliv יעדכן את האפליקציה.
Slack הוא משטח עבודה. האפליקציה יכולה לפרסם בקשות ממתינות ל-Slack ולתעד אישורים חזרה במסד הנתונים. פרטי ההתחברות נשמרים בכספת של הפלטפורמה, לא בקוד.
ניתן לבדוק אישור עצמי. Kliv יכול להריץ תרחיש שבו מבקש מנסה לאשר בקשה משלו בסך 14,000 ₪ ולוודא שהניסיון נדחה.
זמן המחזור ניתן למדידה. זמן-להחלטה לכל מאשר, בקשות שהוחזרו, והוצאות לפי מרכז עלות ניתנים לדיווח מאותן שורות.
תהליכי אישור מובילים לעיתים קרובות לכלים פנימיים נוספים; עמוד הכלים הפנימיים עוקב אחר אותו דפוס.
שאלות נפוצות
מה זה בעצם Kliv?
Kliv הוא בנאי אפליקציות מבוסס בינה מלאכותית. אתם מתארים את כללי האישור שלכם, והוא בונה אפליקציה אמיתית לבקשות, ניתוב, החלטות, האצלה, דוחות, ותיעוד ביקורת.
אני מקבל אפליקציה אמיתית, או תבנית?
אפליקציה אמיתית. הספים, הקטגוריות, שרשראות המאשרים, כללי הנראות, והדוחות שלכם בנויים לתוך מסד הנתונים והמסכים.
אפשר לשנות אותה אחרי שהיא נבנתה?
כן. תוכלו לשנות ספים, מאשרים, קטגוריות, ערוצי Slack, דוחות, או כללי האצלה פשוט על ידי בקשה.
אפשר לערוך היסטוריה בדיעבד?
לא. החלטות הן רשומות שניתן רק להוסיף אליהן, עם גורם מבצע וחותמת זמן. תיקון הוא רשומה חדשה שמפנה לישנה.
מה קורה כשמאשר נמצא בחופשה?
רשומות האצלה מכסות תאריך התחלה וסיום מוגדרים, והחלטות שהתקבלו במסגרת האצלה מציינות זאת.
האם שינויי כללים משפיעים על בקשות שכבר בתהליך?
לא בהכרח. כברירת מחדל, בקשה יכולה לשמור על הניתוב שהוקצה לה, כאשר גרסת הכלל הזו נשמרת על הבקשה.
מאשרים יכולים לפעול מתוך Slack?
כן. האפליקציה יכולה לפרסם בקשות ממתינות ל-Slack ולתעד את הפעולה חזרה בתיעוד האישורים.
איך מאשרים מתחברים?
עם חשבונות באפליקציה שלכם: אימייל וסיסמה, כניסה עם Google, מפתחות גישה (passkeys), ואימות דו-שלבי אם תרצו.
מבקשים יכולים לראות בקשות של אנשים אחרים?
רק אם תאפשרו זאת. ההגדרה הרגילה היא שמבקשים רואים את הבקשות שלהם, מאשרים רואים את התורים שלהם, וכספים רואה הכל.
אפשר להשתמש בדומיין שלי?
כן. האפליקציה יכולה לרוץ על הדומיין שלכם.
אפשר לעבור מ-Kliv בהמשך?
כן. הקוד של האפליקציה מסתנכרן למאגר ה-Git שלכם, כך שעזיבה היא פשוט git pull ולא בנייה מחדש.
תפסיקו לאשר דברים על ידי העברתם הלאה
תארו את הספים, שרשרת האישורים, ההאצלות, והדוחות בדיוק כפי שהייתם מסבירים אותם לעובד חדש. Kliv בונה את התהליך מהתיאור הזה.
