חדשנות מוצר ופיתוח יישומים

מרעיון עסקי למוצר דיגיטלי שמוכן לסביבת הייצור

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

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

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

רעיונות שונים. משמעת מוצר אחת.

אותה משמעת משרתת שלושה מצבים שונים למדי:

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

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

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

להתחיל מהבעיה העסקית

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

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

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

גילוי מוצר

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

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

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

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

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

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

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

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

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

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

יישומים שנבנים סביב צרכים עסקיים

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

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

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

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

בינה מלאכותית במוצר — ובינה מלאכותית בתהליך ההנדסה

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

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

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

יישומים נתמכי בינה מלאכותית

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

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

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

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

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

הנדסה נתמכת בינה מלאכותית

בתוך תהליך ההנדסה, הסיוע של הבינה המלאכותית יכול לתמוך בצוותים מנוסים ב:

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

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

אחריות אנושית

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

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

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

בנוי כדי להתפתח

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

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

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

אבטחה ושליטה בנתונים

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

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

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

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

ייצור הוא רף אחר

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

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

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

כיצד אפשר לעצב התקשרות

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

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

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

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

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

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

דוגמאות לסוגי מוצרים

אלה המחשות למה שעבודה מסוג זה מייצרת, ולא רשימה של מוצרים קיימים של VODIS:

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

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

תוצרים אפשריים

בהתאם להיקף המוסכם, התקשרות יכולה להפיק:

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

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

נדבר על רעיון המוצר או היישום שלכם