ServiceNow מפתחת סוכן AI ל־No-Code ול־Low-Code

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

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

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

אפליקציה ללא קוד כבר לא עוצרת בטפסים וזרימות עבודה

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

זה שינוי חשוב. עד לא מזמן, כשאמרו "סוכן AI", התמונה הייתה של פרויקט מורכב עם מודלים, אימון נתונים, בדיקות ארוכות ואינטגרציות תובעניות. כלי No-Code ו-Low-Code לא מבטלים את המורכבות לגמרי, אבל הם כן משנים את נקודת הכניסה. במקום להתחיל מקוד, מתחילים מהמקרה העסקי.

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

מה בדיוק ServiceNow מנסה לפתור

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

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

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

למה No-Code ו-Low-Code חשובים כאן באמת

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

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

כאן נכנסת גישת ה-Low-Code וה-No-Code. היא מאפשרת לבעלי הידע העסקי להיות קרובים יותר לבנייה עצמה. לא במקום אנשי הטכנולוגיה, אלא לצדם. מנהל שירות יכול להגדיר אילו שאלות נפוצות יטופלו אוטומטית. צוות HR יכול לבנות תסריטי שיחה לעובדים חדשים. אנשי IT יכולים לקבוע מתי הסוכן פותר לבד ומתי הוא פותח קריאה ומעביר לטיפול אנושי.

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

איך נראה סוכן כזה ביום עבודה רגיל

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

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

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

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

לא רק חיסכון: שינוי באופן שבו ארגון עובד

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

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

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

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

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

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

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

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

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

איך לבחור פתרון מתאים לפי הארגון, ולא לפי ההייפ

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

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

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

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

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

איפה הסיכונים נמצאים

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

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

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

מה המשמעות עבור מי שמתעניין בפיתוח אפליקציות ללא קוד

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

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

אבל כדאי לזכור: כלי No-Code טוב אינו תחליף לחשיבה מוצרית. הוא פשוט מאפשר לממש אותה מהר יותר.

השורה התחתונה: לא כל ארגון צריך להתחיל בגדול

הכוח האמיתי של סוכן AI בגישת No-Code או Low-Code אינו בכך שהוא יודע לעשות הכול, אלא בכך שאפשר להפעיל אותו מהר יחסית על בעיה ממוקדת ולראות ערך. זהו יתרון ניהולי לא פחות מטכנולוגי.

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

ServiceNow מזהה היטב את הכיוון הזה. בעידן שבו ארגונים מחפשים פחות מצגות ויותר תוצאות, השילוב בין AI לבין פלטפורמות No-Code ו-Low-Code עשוי להפוך לאחת הדרכים המעשיות ביותר להוציא אוטומציה מהשולחן האסטרטגי אל העבודה היומיומית.

טבלת סיכום: מה חשוב להבין לפני שמטמיעים סוכן AI ב-No-Code

שאלות שכדאי לשאול לפני שמתקדמים

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

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

3. מי בארגון צריך להיות שותף לבנייה: IT, שירות, HR, תפעול, אבטחת מידע או בעלי התהליך העסקי?

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

5. האם אנחנו צריכים כלי פשוט לפיילוט מהיר, או פלטפורמה רחבה שתוכל לשרת כמה מחלקות לאורך זמן?