הגדרת אישור מסמכים באמצעות תהליכים עסקיים ב-Bitrix24

אישור חוזים נתקע בדואר האלקטרוני ובאפליקציות מסרים, ואת הסטטוס צריך לברר ידנית. אנו מגדירים אישור מסמכים ב-Bitrix24 מקצה לקצה: מסלולים, תפקידים, מועדים והתראות — בהתאם לנהלים שלכם. מחזור מעבר החוזה מתקצר פי כמה, ולכל מסמך נשמרת היסטוריה שקופה.
השירותים שאנו מציעים
מציג 1 מתוך 1כל 1626 השירותים
הגדרת אישור מסמכים באמצעות תהליכים עסקיים ב-Bitrix24
פשוט
~1 יום

הכישורים שלנו:

שאלות נפוצות

תיאום מסמכים ב‑Битрикс24: היכן התהליך נשבר

כל עוד תיאום מסמכים ב‑Битрикс24 לא בנוי כתהליך, חוזים ובקשות חיים במייל ובמסרים. היועץ המשפטי שולח תיקונים כקובץ מצורף, המנהל המסחרי עונה "אוקיי" בצ'אט, הנהלת החשבונות מבקשת "אותה גרסה, אבל עם מחיר חדש". על השאלה היכן נמצא כעת חוזה מסוים, אף אחד לא עונה בלי להתכתב.

כך הולכת לאיבוד גרסת המסמך: תיקון חוזר לקובץ שכבר התפזר בשלושה עותקים, ומה שנחתם הוא העותק הרביעי. תיאום ידני במייל לא מותיר עקבה של מי מחזיק במסמך וכמה ימים הוא מונח אצלו — משך המעבר אינו נמדד על ידי איש, כי אין נקודת התחלה.

בעקבות כך מופיע תיאום תקוע: השלב פורמלית מתנהל, האחראי בחופשה, והמשימה לא הועברה לאף אחד. את מסלול תיאום החוזה במצב כזה משחזרים בדיעבד לפי ההתכתבות, ולא לפי יומן הפורטל — ועל העיכוב נודע מהצד הנגדי, ולא מהמערכת.

בתוך הפורטל זה נבנה אחרת: כרטיס המסמך מקושר לעסקה או לבקשה, המסלול מוגדר בתהליך עסקי, לכל שלב יש מועד, אחראי ומחליף, וכל הגרסאות נשמרות במקום אחד עם היסטוריית שינויים. בהמשך נפרט היכן בדיוק נשבר התהליך וכיצד זה נסגר באמצעות הגדרה.

מה משתנה לאחר ההגדרה: זמן, בקרה, מרשם

לפני ההגדרה איש אינו מודד את משך מעבר המסמך: הוא חי במייל, בצ'אטים ובתיקיות אישיות, והמועד הקובע צף דווקא כשכבר הופר. תהליך עסקי ב‑Битрикс24 הופך את המסלול לתרשים בר‑ביצוע — עם אחראי בכל שלב, מועד ותזכורת. המסמך מפסיק להיות תלוי בשאלה אם המאשר זוכר את המשימה שלו.

כל תיקון נשמר כגרסה נפרדת: רואים מי שינה ומה שינה, מה היה הערה ומה היה הנוסח הסופי. היסטוריית גרסאות המסמך מסירה את הוויכוחים "אישרנו גרסה אחרת": ניתן לשחזר כל גרסה קודמת, והמסמך חוזר לעבודה מהשלב שבו נעצר, בלי לעבור שוב את כל המסלול.

מרשם תיאומים אחיד מחליף חיפוש ידני בהתכתבות: ברשימה אחת — מה נמצא בבדיקה, אצל מי, כמה זמן זה שם ומה נדחה עם סיבה. שקיפות הסטטוסים עובדת גם עבור היוזם וגם עבור המנהל: צוואר הבקבוק נראה לפי השלב שבו המסמכים מצטברים הכי הרבה זמן, ולא לפי ההחמצה הסופית של המועד.

מכאן — בקרת משמעת ביצועית בלי תזכורות ידניות: לגבי כל משתתף רואים זמן תגובה ממוצע ושיעור איחורים, ולכן השיחה היא על מספרים ולא על impressions. נעלם סוג שלם של כשלים כמו "המסמך אבד בהתכתבות" — המערכת עצמה מחזירה את המשימה, מסלימה איחור ומתעדת את התוצאה.

אפשרויות מסלולי תיאום: השוואת מצבים

ב‑Битрикс24 מסלול התיאום הוא תהליך עסקי, ומצב הביצוע שלו נקבע כבר בהתחלה: סדרתי, מקבילי או משולב. מסלול קשיח מגדיר את המאשרים ישירות בתבנית התהליך, וכללים רכים לוקחים את הרכב המשתתפים משדות המסמך — היחידה של היוזם, קטגוריית החוזה, סוג הצד הנגדי.

אפשרות מתי מתאימה מגבלות
תיאום סדרתי החתימה של כל משתתף משנה את המסמך או מחייבת משפטית המשך גדל באופן לינארי: החתימה החמישית ממתינה לארבע הקודמות
תיאום מקבילי המאשרים בלתי תלויים ואינם מתקנים זה את זה פערים בין תיקונים מגשר היוזם — נדרש פרוטוקול מסכם
מסלול משולב חלק מהשלבים קפדניים, חלקם לידיעה בלבד קשה יותר לכיול: שגיאה בענף נראית רק בהרצה
מסלול קשיח התקנון קבוע ומשתנה לעיתים נדירות כל שינוי — תיקון תבנית התהליך, ולא של ההגדרות
מעבר מותנה לפי סף סכום החוזה מסמכים קטנים לא צריכים לעבור דרך המנהל הכללי נדרש סדר מילוי שדות: שדה ריק שובר את התנאי

מעבר מותנה בתהליך בודק את השדות: אם סף סכום החוזה חרג — מתווסף שלב עם המנהל הכספי, אם לא — המסלול נסגר אצל המנהל. בנפרד אנחנו מגדירים נקודת התערבות ידנית: מנהל המערכת מקצה מחדש משימה או מדלג על שלב, אבל כל פעולה נרשמת בהיסטוריית התהליך. לכן בחירת המצב היא פשרה בין משך התיאום לבין יכולת החיזוי של המסלול.

שלבי ההטמעה: מביקורת תהליכים ועד מסירה

סדר העבודות כאן חשוב יותר מהמהירות: אם קודם מגדירים כללים ורק אחר כך מגלים שחצי מהמסלולים בחברה פועלים אחרת, את התרשים צריך להרכיב מחדש יחד עם ההרשאות והמסמכים שכבר הופעלו. לכן אנחנו פועלים ברצף — מניתוח התהליכים הקיימים ועד המסירה, ותוצאה מתועדת בכל שלב.

  1. ביקורת תהליכים עסקיים. מנתחים כיצד התיאום מתנהל כעת: מי יוזם, מי מאשר, בשלב איזה מסמך "נתקע" לרוב, היכן מקבלים החלטות במייל ובמסרים מחוץ למערכת.
  2. תכנון תרשים מסלול התיאום. מרכיבים מפת שלבים: ענפים סדרתיים ומקביליים, תנאי מעבר, מועדים בכל שלב, הסלמה למנהל בשעת שתיקה והחזרה לתיקון עם היסטוריית שינויים.
  3. הגדרת הרשאות גישה. תפקידים וקבוצות, נראות כרטיס המסמך לפי יחידות, הרשאת אישור, הרשאת ביטול אישור, איסור שינוי הקובץ לאחר אישור — כך שחלוקת האחריות נשענת על כללים ולא על הסכמות.
  4. בדיקות על מסמכים אמיתיים. מריצים עותקים מונפשים של חוזים ובקשות טיפוסיים, כולל מקרים לא נוחים: מאשר בחופשה, החלפת חותם, דחייה בשלב האחרון. שגיאות במסלול נתפסות לפני ההפעלה, ולא על מסמך חי.
  5. העברת מסמכים פעילים. קובעים מה מסיימים לתאם לפי הכללים הישנים ומה מעבירים למסלול החדש, כדי לא לאבד היסטוריה ולא לקרוע מחזורים שכבר החלו.
  6. מסירה לתפעול והדרכה. מוסרים את תרשים המסלול, תקנון האישור והוראות לעובדים ולמנהל המערכת, ומראים כיצד להוסיף מאשרים חדשים ולשנות מועדים בלי להרכיב מחדש את התהליך.

תצורות, תרשימים ותקנונים: מה נשאר אצלכם

מסלול תיאום מסמכים מוגדר ב‑Битрикс24 מחזיק בדיוק עד השינוי הראשון בכוח האדם: עובד חדש לא יודע איזה שלב אסור לדלג עליו, ומנהל המערכת — מדוע בענף דווקא התנאי הזה.

לכן אנחנו מוסרים לא רק תצורה עובדת, אלא גם את השכבה שלפיה אפשר לפתח אותה בלעדינו — הכול נמצא בפורטל שלכם, מקושר לתבניות תהליכים ולתפקידים מסוימים, ולא לשמות משפחה.

  • תרשימי מסלולים לכל סוג מסמך — נקודות הסתעפות, תנאי מעבר, מועדים לשלב ופעולות אוטומטיות: התראה, פתיחת משימה, שינוי שלב, נעילת עריכה.
  • מטריצת הרשאות ותפקידים — מי יוזם, מי מתאם, מי מאשר, מי רק צופה ומי מחליף נעדר; קישור למחלקות ולתפקידים.
  • הוראות משתמש — תרחישים לכל תפקיד: כיצד לשלוח מסמך, מה לעשות בהחזרה לתיקון, היכן לראות היסטוריה ואת האחראי הנוכחי.
  • תקנון ביצוע שינויים — סדר תיקון המסלול, מי מאשר את הלוגיקה החדשה, כיצד נבדקת הגרסה בסביבת בדיקה לפני הכללתה בסביבת העבודה.
  • תיעוד התהליך — מפת שדות, סטטוסים ותבניות וכן יומן גרסאות עם תשובה לשאלה מה ומדוע השתנה.
  • ערכת מנהל המערכת — היכן נשמרות ההגדרות, כיצד להעביר את התהליך לפורטל אחר, מה לבדוק לאחר עדכון כדי שהתיאום לא ייעצר.

דוגמה מהשטח: מחזור מעבר החוזים הצטמצם פי שלושה

אצל הלקוח — מחלקה משפטית וארבע יחידות — החוזה עבר בשרשרת סדרתית: משפטי, כספים, ראש אגף, מנהל מסחרי, מנהל כללי. המחזור נמשך מתשעה עד שנים עשר ימים, גרסאות הקבצים התפזרו במייל, ועל השאלה "היכן המסמך כעת" ענו בשיחת טלפון לאחראי.

אנחנו מפו את המסלול בפועל והעברנו אותו לתהליך עסקי ב‑Битрикс24: שלבים עם הקצאה לתפקיד ולא לעובד מסוים, ענפים מקביליים למשפטי ולכספים, מועד לכל שלב, תזכורות אוטומטיות וכלל החלפה לתקופת חופשה או מחלה. תיקונים מוזנים לכרטיס המסמך, ולא לקובץ שנשלח — המאשר תמיד רואה את הגרסה העדכנית.

מדדים לפני ואחרי

מדד לפני ההטמעה אחרי
מאשרים בשרשרת 5, בסדרה 5, מתוכם 3 במקביל
מחזור תיאום החוזה 9–12 ימים 3–4 ימים
חוזים עם איחור בשלב כ‑40% 5–7%
תיקונים שהוזנו לאחר התיאום נמצאו באופן קבוע לא תועדו

בנפרד נעלם סוג כשלים שלא נספר קודם כלל: תיאום גרסה שכבר הוחלפה; מסמך שנשלח למשתתף לא נכון; שלב שאיש לא פיקח על המועד שלו.

כעת לכל פעולה יש מחבר ותווית זמן, והחזרת מסמך מהשלב האחרון מחזירה אותו בדיוק לנקודה במסלול שבה נדרש תיקון — בלי להרכיב מחדש את השרשרת ובלי לעבור שוב את כל המאשרים.

במה נבדלים תהליכים עסקיים קלאסיים מתהליכים חכמים

ההבדל בין המנגנונים אינו בממשק, אלא היכן נשמרים נתוני כרטיס המסמך. תהליך עסקי קלאסי הוא תרחיש תיאום: הוא מופעל על רכיב מסוים (קובץ, רשומת CRM, רכיב אינפובלוק) ושומר את המצב במופע משלו. תהליך חכם ב‑Битрикс24 הוא ישות נפרדת עם סט שדות משלה, כרטיס, שלבים והרשאות גישה, כמו רכיבי CRM.

מכאן גם ההבדל בקשרים בין הישויות. תהליך חכם מקושר באופן תקני לחברה, לאיש קשר, לעסקה ולתהליכים חכמים אחרים, ושליפות ודוחות נבנים לפי השדות שלו. תהליך קלאסי קשור לרכיב אחד, ולכן מרשם לפיו נאסף ידנית — דרך רשימות, דוחות או ייצוא.

בחירת המנגנון למשימה נקבעת לפי אופי הזרימה. עבור מרשם חוזים ניקח תהליך חכם: נדרשים סינונים לפי צד נגדי ומועד, דיווח, אוטומציות לפי שלבים ותזכורות על הארכה.

עבור בקשה חד‑פעמית מהיר יותר תהליך קלאסי — אין צורך להקים ישות חדשה, להגדיר הרשאות וכרטיס, והתיאום מופעל ישירות על רשומה קיימת.

בפועל עובד לרוב היבריד: כרטיס המסמך והקשרים חיים בתהליך חכם, ומסלול התיאום עצמו בתוכו מופעל בתהליך קלאסי.

ספקות טכניים לפני ההתחלה: מענה לשאלות

לפני תחילת העבודות על תיאום מסמכים, מהנדסים ומנהלי אגפים שואלים פחות או יותר את אותן שאלות: מה יקרה למסלולים הקיימים, האם תישמר הגישה לעובדים שהוסרו, וכיצד לשנות את התרשים בלי לעצור את המחלקה. להלן — תשובות בלי מילים כלליות, כפי שזה בנוי ב‑Битрикс24.

כיצד מועברים מסלולי תיאום שכבר פועלים?

אוספים את התרשימים הקיימים: משתתפים לפי שלבים, תנאי הסתעפות, כללי החזרה לתיקון, תבניות כרטיסים וטפסי הדפסה. לאחר מכן משחזרים אותם בתהליכים עסקיים בסביבת בדיקה ומריצים מסמך אמיתי בכל הענפים, כולל דחייה ותיאום חוזר. פערים מתקנים לפני שהמשתמשים רואים את הסדר החדש.

האם נדרש חיבור קבוע למערכת לצורך התיאום?

לא. המשימה מגיעה בהתראות הפורטל, וההחלטה מתקבלת מהדפדפן או מאפליקציית המובייל — אין צורך להתקין לקוח נפרד על עמדת העבודה. עובד בנסיעת עבודה או בעבודה מרחוק פועל באותו מסלול; אם אין חיבור, המשימה פשוט ממתינה לחזרתו למערכת.

האם אפשר לשנות את התהליך בלי לעצור את התיאום?

כן. גרסה חדשה של התבנית מפורסמת בנפרד: מופעים שכבר הופעלו מסתיימים לפי הלוגיקה הישנה, וחדשים מתחילים לפי השונה. הוספת מאשר, תיקון תנאי או סדר שלבים אינו מחייב עצירת התהליך והפעלה מחדש של מסמכים באופן ידני.

כיצד מוגבלת הגישה למסמך עצמו?

ההרשאות מוגדרות ברמת הכרטיס, התיקייה והשלב: משתתף רואה רק את השלב שלו ואת הקבצים המצורפים אליו, ושאר המדורים אינם נגישים לו. הורדה והדפסה ניתן לכבות בנפרד, וכל הפעולות — צפייה, תיקון, שליחה — נרשמות ביומן עם המחבר והשעה.

מה קורה עם מסמכים שכבר הועלו?

הם נשארים במערכת: עבורם מפעילים את התהליך לפי אירוע או ידנית, תוך שליפת שדות מהכרטיס — אין צורך להעלות את הקבצים שוב. אם למסמך כבר יש היסטוריית תיאום, היא נשמרת, לא נוצרים כפילויות, והמספור והקשרים עם הצדדים הנגדיים אינם נקטעים.

נדון במשימה: במה מתחילים את העבודה

תיאום מסמכים ב‑Битрикс24 כמעט אף פעם אינו מצטמצם לתבנית אחת: חשוב מי משתתף, באיזה שלב, מה עושים בעת דחייה וכיצד מתועדת התוצאה. כדי לדון במשימה באופן ענייני ולחזור עם הערכה, ולא עם מילים כלליות, יש צורך במינימום נתוני פתיחה — הרשימה שלהלן מסירה את רוב אי‑הוודאות עוד לפני ההתחלה.

  • תפקידי המשתתפים: מי יוזם, מי מתאם, מי מאשר, מי מקבל עותק — מכך נגזר תרשים המסלול.
  • סוגי המסמכים וההיקף: חוזים, חשבוניות, תזכירים פנימיים — כמה פריטים בחודש ומה גודל הקבצים.
  • סדר העבודה הקיים: כיצד המסלול נראה כעת — במייל, בטבלאות או על נייר.
  • כללי הסתעפות: מה קורה בעת דחייה, האם נדרשת שליחה חוזרת, האם אפשר לשנות מסלול תוך כדי תנועה.
  • אחסון והרשאות: היכן נמצא הקובץ, מי רואה את היסטוריית הגרסאות, מי אחראי על הארכיון.
  • נקודות אינטגרציה: 1С, דואר, דיסק, צדדים נגדיים — מה אמור לקבל נתונים באופן אוטומטי.
  • מגבלות: מועדים, זמינות מנהל הפורטל, האם אפשר לשנות תהליכים בלי לעצור את העבודה.

הצעד הראשון בפרויקט — ניתוח נתוני הפתיחה הללו: משווים את המסלול ליכולות הפורטל וחוזרים עם הערכה ותוכנית עבודה. בתוכנית מתעדים את הרכב העבודות לפי שלבים, אזורי אחריות וסדר הקבלה, כך שלפני ההתחלה יהיה ברור מה בדיוק משתנה בתיאום המסמכים.