תארו לעצמכם: חוזה לאישור, אבל הסכום משנה את המסלול, עורך הדין בחופשה — המשימה עפה לסגן, ואם נדחתה, המערכת מחזירה אותה אוטומטית ליוזם עם הערה. ללא לוגיקה מותאמת אישית, תרחישים כאלה בלתי אפשריים: בונה התהליכים הסטנדרטי של Bitrix24 מטפל רק במסלולים ליניאריים עם משתתפים קבועים. לפי הסטטיסטיקה שלנו, 70% מהפרויקטים דורשים חוקים דינמיים — אישורים רב-שלביים, אינטגרציה עם 1C, SLA עם ספים. לדוגמה, חברה אחת עם מחזור של $4.5M–6.5M צמצמה את זמן אישור החוזים ב-60% לאחר יישום תהליכים מותאמים אישית. אנו בונים תהליכי אישור מותאמים אישית מקצה לקצה: מניתוח דרישות ועד הטמעה והדרכה. נבחן את הפרויקט שלכם תוך יומיים — פשוט צרו קשר.
מדוע תהליכי אישור מותאמים אישית פותרים מה שהבונה הסטנדרטי לא יכול?
לבונה תהליכי העסקים הסטנדרטי יש מגבלות חמורות: יותר מ-3–4 ענפים הופכים את הסכמה לבלתי קריאה, משתתפים דינמיים דורשים קוד PHP, וגרסאות תהליך אינן קיימות. הניסיון שלנו מראה ש-70% מהפרויקטים זקוקים ללוגיקה מותאמת אישית: מסלולים מותנים מורכבים, אינטגרציה עם REST API או מערכות חיצוניות.
כיצד אנו בונים תהליכים מותאמים אישית?
הבסיס הוא שלוש גישות, הנבחרות לפי המשימה:
- בלוקי פעילות מותאמים אישית — אנו מוסיפים מחלקות PHP משלנו לבונה. הן גמישות פי 3 מהסטנדרטיות כי הן אינן מוגבלות על ידי הטופס.
- תהליכים חכמים של CRM עם רובוטים — להסתעפות פשוטה ב-CRM.
- יישום מותאם אישית מלא דרך REST API — לגמישות מרבית.
כיצד ליצור בלוק פעילות מותאם אישית?
פעילות היא מחלקת PHP המיישמת \Bitrix\Bizproc\Activity\Base. היא מופיעה בבונה כבלוק סטנדרטי אך מכילה לוגיקה שרירותית.
class SendToErpActivity extends \Bitrix\Bizproc\Activity\Base { public function execute(\CBPActivity $activity): \CBPActivityExecutionStatus { $dealId = $activity->getDealId(); // получаем параметр из БП $erpClient = new ErpApiClient(); $result = $erpClient->createApprovalRequest($dealId); if ($result->isSuccess()) { $activity->setVariable('ERP_REQUEST_ID', $result->getId()); return \CBPActivityExecutionStatus::Closed; } // Ошибка — можем вернуть Faulting для обработки в БП return \CBPActivityExecutionStatus::Faulting; } } הבלוק נרשם ב-class SendToErpActivity extends \Bitrix\Bizproc\Activity\Base { public function execute(\CBPActivity $activity): \CBPActivityExecutionStatus { $dealId = $activity->getDealId(); // получаем параметр из БП $erpClient = new ErpApiClient(); $result = $erpClient->createApprovalRequest($dealId); if ($result->isSuccess()) { $activity->setVariable('ERP_REQUEST_ID', $result->getId()); return \CBPActivityExecutionStatus::Closed; } // Ошибка — можем вернуть Faulting для обработки в БП return \CBPActivityExecutionStatus::Faulting; } } או bitrix/activities/. לאחר הרישום, הוא מופיע בבונה כאלמנט סטנדרטי ותומך בהגדרת פרמטרים דרך טופס.
כיצד ליישם משתתפים דינמיים?
רשימת מאשרים הנקבעת לפי נתוני המסמך היא בקשה נפוצה. לדוגמה: סכום עסקה עד $4.5k–6.5k — מאושר על ידי ראש המחלקה, מ-500,000 עד 2,000,000 — בתוספת המנהל הפיננסי, מעל — בתוספת המנכ"ל. ולכל מחלקה, מטריצה שונה.
יישום: בלוק פעילות "קביעת מאשרים" מחשב את רשימת המשתמשים לפי נתוני המסמך וטבלת סמכויות. טבלת הסמכויות נשמרת ב-HL-block או בטבלת DB נפרדת. התוצאה היא מערך של מזההי משתמשים, המועבר לבלוק "אישור" הבא כפרמטר.
// HL-блок "Полномочия согласования" // Поля: DEPARTMENT_ID, AMOUNT_FROM, AMOUNT_TO, APPROVER_USER_ID, APPROVER_ROLE $approvers = ApprovalMatrixTable::getList([ 'filter' => [ 'DEPARTMENT_ID' => $departmentId, '<=AMOUNT_FROM' => $amount, '>=AMOUNT_TO' => $amount, ], ]); כיצד לארגן מחליפים והאצלה?
מאשר בחופשה או בנסיעת עסקים — התהליך לא צריך להיתקע. שתי אפשרויות:
- האצלה אוטומטית: לפני שליחת המשימה, אנו בודקים את סטטוס המשתמש (דרך
/local/activities/או שדה פרופיל מותאם אישית "מחליף"). אם המשתמש נעדר — המשימה עוברת לסגן. - האצלה לאחר פסק זמן: אם המשימה לא הושלמה תוך X שעות — היא עוברת גם לסגן. מיושם דרך בלוק "השהיה" בתהליך עסקי + תנאי.
אנו מתחזקים מטריצת החלפה ב-HL-block: // HL-блок "Полномочия согласования" // Поля: DEPARTMENT_ID, AMOUNT_FROM, AMOUNT_TO, APPROVER_USER_ID, APPROVER_ROLE $approvers = ApprovalMatrixTable::getList([ 'filter' => [ 'DEPARTMENT_ID' => $departmentId, '<=AMOUNT_FROM' => $amount, '>=AMOUNT_TO' => $amount, ], ]); , user.get, USER_ID, SUBSTITUTE_USER_ID. בלוק הפעילות בודק את המחליף הנוכחי בזמן ההפעלה.
כיצד ליישם אישור מקבילי עם סף?
שלושה מאשרים בו-זמנית, נדרשים שניים "מאשרים":
[Параллельный блок] ├── Задача: Согласующий 1 ├── Задача: Согласующий 2 └── Задача: Согласующий 3 [Блок ожидания: 2 из 3 завершены с результатом "Согласовано"] [Условие: результат?] ├── Да → Следующий этап └── Нет → Отклонено בבונה הסטנדרטי, זה מיושם דרך "פעילות מקבילית" + פעילות מותאמת אישית "צבירת קולות". הפעילות עוקבת אחר הצטברות התשובות במשתנה תהליך עסקי ומחזירה DATE_FROM רק כאשר הסף מושג.
כיצד לשמור היסטוריית אישורים וביקורת?
כל פעולת מאשר מתועדת:
- בהערת המסמך דרך
DATE_TO - ב-HL-block נפרד "היסטוריית אישורים" עם שדות: תאריך, משתמש, פעולה, הערה, גרסת מסמך
האפשרות השנייה עדיפה — היא מאפשרת בניית דוחות: כמה פעמים בממוצע מסמך עובר סבבי אישור, איזה מאשר דוחה הכי הרבה, מהו זמן האישור הממוצע לפי סוג מסמך.
כיצד להגדיר הסלמה ו-SLA?
לכל שלב מוגדר SLA (זמן השלמה). אם המועד מופר:
- הודעה למאשר עצמו
- הודעה למנהל שלו
- לאחר הסף השני — החלטה אוטומטית כברירת מחדל (אישור אוטומטי או הסלמה גבוהה יותר)
מיושם דרך סוכני Bitrix או דרך מתזמן ביישום מותאם אישית.
השוואה: גישה סטנדרטית מול מותאמת אישית
| פרמטר | בונה סטנדרטי | פיתוח מותאם אישית |
|---|---|---|
| מסלולים מותנים (>3 ענפים) | בלתי קריא | לוגיקה ברורה בקוד |
| משתתפים דינמיים | רק דרך קוד PHP | בלוק ייעודי עם HL-block |
| החלפה | הקצאה ידנית מחדש | אוטומטית דרך מטריצה |
| מקבילי עם סף | דורש עקיפות | פעילות מוכנה |
| גרסאות | לא קיים | נתמך |
סוגי תהליכים מותאמים אישית
| סוג | גמישות | מורכבות פיתוח | דוגמת שימוש |
|---|---|---|---|
| בלוקי פעילות | בינונית | בינונית | לוגיקה שרירותית בתהליך עסקי |
| תהליכים חכמים | נמוכה | נמוכה | הסתעפות פשוטה ב-CRM |
| יישומי REST | גבוהה | גבוהה | התאמה מלאה ואינטגרציה |
כיצד ליישם רשימת מאשרים דינמית: מדריך שלב-אחר-שלב
- צרו HL-block "סמכויות אישור" עם שדות: מחלקה, סכום מ, סכום עד, תפקיד, מזהה משתמש.
- פתחו בלוק פעילות השואל את ה-HL-block לפי נתוני המסמך ומחזיר מערך מאשרים.
- רשמו את הפעילות בבונה התהליכים העסקיים דרך
[Параллельный блок] ├── Задача: Согласующий 1 ├── Задача: Согласующий 2 └── Задача: Согласующий 3 [Блок ожидания: 2 из 3 завершены с результатом "Согласовано"] [Условие: результат?] ├── Да → Следующий этап └── Нет → Отклонено. - בתהליך, לאחר בלוק "קביעת מאשרים", הוסיפו בלוק "אישור" סטנדרטי וציינו את המשתנה עם המשתתפים.
מה כלול בעבודה ולוחות זמנים
- תיעוד: מפת מסלול, מטריצת סמכויות, SLA
- פיתוח פעילויות מותאמות אישית ו-HL-blocks
- הגדרת החלפה והסלמה
- אינטגרציה עם מערכות חיצוניות (1C, ERP, Telegram)
- הדרכת מנהלים ו-30 ימי תמיכה
לוחות הזמנים תלויים במורכבות: משבועיים לתהליך בסיסי ועד 6 שבועות עם אינטגרציית ERP. העלות מחושבת באופן אישי — נבחן את הפרויקט שלכם תוך יומיים לאחר בריף. קבלו ייעוץ — צרו קשר.
מידע נוסף על יישום החלפה
בהאצלה אוטומטית, בדיקת הסטטוס נעשית באמצעות Closed. אם המשתמש נעדר (חופשה, מחלה), המערכת מחליפה את הסגן מה-HL-block. להאצלה לפי פסק זמן, נעשה שימוש בסוכן הפועל לאחר מספר שעות מוגדר משליחת המשימה.
מערכת אישורים בוגרת אינה תהליך עסקי מוגדר בבונה, אלא סט של בלוקים מותאמים אישית, חוקי ניתוב ובסיס ביקורת. אנו מבטיחים פעולה יציבה: מומחים מוסמכים עם ניסיון של למעלה מ-8 שנים ו-50+ פרויקטים. מערכת כזו מחזיקה שנים ודורשת התערבות מינימלית כאשר חוקי העסק משתנים —只需 לעדכן את טבלת הסמכויות. תהליכי אישור מותאמים אישית מחזירים את ההשקעה בממוצע תוך 6 חודשים על ידי הפחתת עבודה ידנית ב-80%. הפתרון מכוונן, ותוכלו לראות זאת בעצמכם — בקשו הדגמה.