פיתוח מערכת AI לאוטומציה של הנפקת אישורים ורישיונות

אוטומציה של הנפקת היתרים עם AI: היכן התהליך נשבר

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

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

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

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

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

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

מה משתנה אחרי ההטמעה: השפעות על המועדים ועל הסירובים

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

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

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

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

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

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

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

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

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

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

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

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

שלבי ההטמעה: מניתוח המסלול ועד מסירת המערכת

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

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

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

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

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

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

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

מקרה בוחן: ניתוח זרימת בקשות בסוג רישיון אחד

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

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

בדיקות אלה ניתנות למפרמל, ולכן העברנו אותן לשכבה אוטומטית: המודל מנתח את חבילת המסמכים, משווה את השדות לנתונים ב-Реестр лицензий ומעביר לבודק כרטיס עם אי-ההתאמות המסומנות במקום ערימת סריקות.

מה השתנה במספרים

זמן הבדיקה הראשונית התקצר מחמישה ימי עבודה לארבע שעות עבור 78% מהבקשות — השאר עוברות לבדיקה ידנית בגלל סריקות שאינן קריאות או נספחים לא סטנדרטיים. שיעור ההחלטות עם בדיקה ידנית ירד מ-100% ל-19%, וההחזרות לתיקון — מ-34% ל-8%.

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

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

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

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

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

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

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

מגבלות וסיכונים: נתונים, אחריות, מקרים שנויים במחלוקת

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

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

האם המודל מוטה?

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

מי אחראי להיתר שהונפק?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

כדי לחזור עם הערכה ותוכנית עבודה, ולא עם הרהורים כלליים, אנחנו זקוקים לנתוני המקור:

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

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