השיטה המדויקת שאינטואיט השתמשה בה כדי לקצר עבודה על קוד מס — ומה זה אומר על העתיד של עבודה רגולטורית

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

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

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

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

שלב #1: איך לזהות את נקודות החנק הרגולטוריות שגוזלות את זמן הצוות שלכם

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

תרגום משפטי-טכני:

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

אימות תאימות:

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

תיאום בין צוותים:

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

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

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

שלב #2: בניית מערכת אוטומציה חכמה שמתרגמת שינויי חקיקה לקוד מבצעי תוך דקות במקום שבועות

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

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

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

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

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

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

שלב #3: יצירת פרוטוקול בדיקה ואישור שמבטיח עמידה בתקנות מבלי להאט את מהירות הפיתוח

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

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

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

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

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

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

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