רשויות מקומיות

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

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

איך התהליך עובד

מקרה בוחן

שירות בקשות ברשות מקומית

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

מה נבדק

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

איפה מחליט אדם

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

תקין

המערכת ממליצה לאשר וקובעת את התוקף. עובד מאשר.

מסמך חסר או שגוי

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

חריג או סתירה

התיק עובר לעובד עם כל הראיות. שום דבר לא מוכרע אוטומטית.

אי־זכאות

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

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

איך שומרים על עקיבות המידע

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

דרישות האינטגרציה

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

• קריאה ועדכון של תיקים במערכת התווים או ניהול הפניות הקיימת, דרך ממשק (API) כשיש כזה.
• גישה למקורות המידע שהכללים נשענים עליהם, כמו מרשם התושבים ונתונים עירוניים נוספים, בכפוף להרשאות ולאישורים של הרשות.
• מערכת הזדהות הארגונית של הרשות לכניסת עובדים ולהרשאות לפי תפקיד.
• דוא״ל או SMS להודעות לתושב, לאחר שהרשות תחליט איזה ערוץ מתאים לכל מסלול.

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

מה צריך להחליט לפני שמתחילים

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

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

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

איך בנוי פיילוט ברשות

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

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