יום שני , אוקטובר 23 2017
מבזקים
דף הבית > כללי > איך מסייעים ללקוח לצאת מברוך כתוצאה מהתקשרות לא מוצלחת עם ספק?

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

מאת: אמיר גולן

אמיר גולן

אמיר גולן

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

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

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

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

  1. נסו לאתר ספק שכבר התנסה עם מספר תהליכים דומים ויש לו הוכחות בשטח.
  2. למדו מן הכישלון שלכם ושתפו בתהליך הלמידה את הספק החדש. תחקרו יחד את תהליך העבודה הקודם ונסו להבין איפה היו המוקשים ומדוע לא ראיתם אותם מראש. הבנה של התהליך הכושל תסייע לכם להימנע מליפול לאותם בורות.
  3. דרשו מהספק הערכות להיקף העבודה אולם קחו בחשבון כי בשל חוסר היכרות קודמת עם התוכנה, יכולה להיווצר סטייה משמעותית במספר שעות העבודה המוערכות. קבלו זאת בהבנה.
  4. דאגו שהספק יגדיר מראש מתודולוגיה מוסדרת של קליטת מערכת קיימת – אופן קבלת קוד המקור, מסדי הנתונים, גישה לסביבות השונות (בדיקות ופרודקשן), קבלת סקירה על המערכת וכו'.
  5. אם ניתן לבצע חפיפה והספק הראשון מוכן לתת סקירת מערכת לספק החדש – מה טוב, אולם ברור כי לא תמיד זה אפשרי.
  6. בצעו מעבר חד בין הספקים. חשוב לזכור שלא ניתן לתחזק מערכת אחת באמצעות שני ספקים במקביל. גם אם הספק החדש עדיין לא מכיר את המערכת מספיק טוב ועדיין לא יודע כיצד יש לטפל בבעיות שצצות זכרו שהוא ילמד תוך כדי תנועה ועם הזמן הפערים יצטמצמו.
  7. עד שהספק החדש לא “ילכלך" את הידיים בקוד הוא לא באמת יבין מה קורה שם. לכן, חשוב להגדיר משימות רוחביות שיגעו בכמה שיותר היבטים של המערכת וכך יאלץ את המפתחים להכיר אזורים רבים ומגוונים שלה, בפרק זמן קצר.
  8. יתכן שהספק החדש יאלץ להשליך שורות קוד לקויות או בלתי מתאימות לפח. עבודה קשה בתחילת הדרך תוביל לתפקוד טוב של המערכת בהמשך.

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

הכותב הוא מנכ"ל משותף בחברת CodeOasis

 

אודות מערכת ITNEWS מאיר עשת

מנהל/עורך אתר ITNEWS. בוגר כלכלה ומנה"ס באונ' בן גוריון ו- MBA בירושליים. בעבר: כהן כיועץ כלכלי מטעם המדינה בהולנד ובהודו. היה סמנכ"ל שיווק בברדר, משנה למנכ"ל בסטארטאפ TVNGO, מנהל IT מגזין של גלובס בשנתיים האחרונות.