הכנה לפרויקט דיגיטלי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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