מה זה Solutions Engineer? הסבר פשוט + כמה משרות פתוחות בישראל

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

מה Solutions Engineer עושה בפועל

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

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

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

אפיון אינטגרציה - השאלות שקובעות אם העסקה אפשרית

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

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

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

לבנות POC שבאמת מוכיח משהו

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

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

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

לדבג API ואימות מול לקוח בזמן אמת

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

קוד	המשמעות המעשית	הסיבה השכיחה בשטח
401	לא הזדהית	טוקן שפג, סביבת בדיקה מול ייצור
403	הזדהית אך אין הרשאה	Scope חסר במפתח או תפקיד לא מתאים
404	המשאב לא נמצא	מזהה מסביבה אחרת או גרסת API שגויה
409	התנגשות מצב	רשומה כפולה או סדר פעולות שגוי
422	המבנה תקין אך התוכן נדחה	שדה חובה חסר, פורמט תאריך
429	חריגה ממגבלת קצב	ייבוא ראשוני ללא האטה
5xx	תקלה בצד שלנו	דיווח פנימי, לא ניחוש מול הלקוח

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

שאלוני אבטחה ורכש - החלק שאף אחד לא מספר עליו

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

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

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

הגבול המדויק מול Presale ומול Solutions Architect

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

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

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

על מה SE נמדד ומה צריך לדעת

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

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

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

שאלות נפוצות

מה ההבדל בין Solutions Engineer לאיש מכירות?

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

האם Solutions Engineer כותב קוד?

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

מה ההבדל בין SE ל-Solutions Architect?

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

איך עוברים לתפקיד SE?

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

מה מכשיל POC בדרך כלל?

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

כמה משרות Solutions Engineer יש בישראל?

חמש משרות בלוח נושאות את הצירוף solutions engineer בכותרת ו-11 מסווגות תחת SOLUTIONS_ENGINEERING, אך רוב התפקידים מפורסמים תחת כותרות רחבות. הרשימות המעשיות הן 61 משרות מכירות ו-26 משרות REST API.

האם התפקיד כולל נסיעות?

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