נקלעתם לברוך עם ספקים? כמה עצות שיעזרו לכם לצאת מזה

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

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

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

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

איך מתגברים?

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

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

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

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

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

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

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

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

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

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

הכותב הוא מנכ"ל משותף ב-CodeOasis.