רבים מאתנו עומדים בפני אישור של פיתוחים גדולים בפרויקטים חדשים או בתוספות שוטפות כאשר מציגים לנו שזו הדרך היחידה להתקדם. נציג כאן דרך פעולה נוספת של עצירה לרגע לפני האישור ובחינת ההשקעה המתוכננת עם מומחים נוספים – Second Opinion.
כדי להמחיש את הצורך והדילמה אספר שני סיפורי מעשה אמתיים:
סיפור שני שהתנסיתי בו אישית – בארגון מסוים התבקשתי להחליף מיישמת מסוימת שהייתה לקראת סוף פרויקט ונבצר ממנה להמשיך באותו רגע. הבנתי שמדובר בפרויקט פיתוח גדול של תוספת למודול PM אחזקה עבור פרויקטים של פיתוח אתרים פיזיים של הארגון. בעיקר עבור כל הצעדים הסטטוטוריים והמעשיים של הליך פיתוח הנכס. התפלאתי מדוע החליטו על פיתוח כי הרי כל הפונקציונליות הזו נמצאת בסטנדרט של מודול ה PS שמיועד לכך. גם הייתי אחרי יישום יפהפה של הפונקציונליות הזו בדיוק ברכבת ישראל עם פרויקטי תשתית אדירים שהיו אז. הוסבר לי שמשתמשת המפתח דרשה שזה יהיה ב PM – כי היא מכירה PM. אמנם נאמר לה שיש את זה ב PS אבל הוחלט ללכת על הפיתוח הגדול. כמובן שכעבור זמן לא גדול אותה משתמשת עזבה את הארגון ואף אחד לא יזכור למה היו צריכים את הפיתוח הענק.
אצל ארגון ציבורי מאוד גדול בישראל רצו פונקציונליות של פירוק והרכבה של עץ של ציוד מסוים עבור אחזקה שלו. מדובר בהעברת הקיט לשימוש שוטף והחזרתו לסדנה לצורך אחזקה, ניקוי והרכבה שוב. שאלו את מיישם הMM הבכיר שעבד אז בארגון האם יש פתרון סאפ סטנדרטי. אמר שלא ואז הלכו לפיתוח שארך כשנתיים וגם עלה ככה. כעבור כמה שנים נכנס לארגון מיישם MM בכיר אחר שהתבקש להוסיף משהו לאותו פיתוח גדול. הוא שאל בתמימות מדוע פיתחו שהרי יש את כל הפונקציונליות של עץ אחזקה בסאפ סטנדרט כולל דוחות יפים, תהליכים מובנים לפירוק והרכבת קיטים וכו'. אבל כמובן שהיה כבר מאוחר מדי והמיישם הראשון כבר מזמן עבר הלאה.
על הדרכים המקובלות לבצע בקרה על פרויקטים גדולים סקרי תכנון כבר עמדתי בפוסט סיעור-מוחות-ובקרת-איכות
על השיקולים השונים לפיתוח כבר עמדתי בפוסט פיתוח-או-סטנדרט
מאז נוספו אפשריות רבות ביישום סטנדרטי וגם בפיתוחים המבוססים על קוד סטנדרטי. ישנם BADI חדשים רבים, יישומי פיורי גם ל ECC וכמובן ל S4, אפשר להוריד אפליקציות מהענן ועוד הרבה כלים חדשים.
אז מדוע ישנם כל כך הרבה סיפורים על פיתוחים מיותרים? (אשמח לשמוע עוד בתגובות שלכם…)
בדקתי את הנושא עם כמה מקבלי החלטות בארגונים. התשובה הפשוטה שקיבלתי היתה – כי אנחנו סומכים מקצועית על המיישמים המובילים שלנו!
OK, בסדר, בואו נזרום עם זה. אז נפרגן ונניח שהמיישמים המובילים הם אחלה ומקצוענים, מיצו את כל האפשרויות הסטנדרטיות, עשו מחקר ובדקו את כל החלופות הידועות להם.
אבל אף אחד מאתנו אינו מושלם, כולנו עושים טעויות ולפעמים לא בודקים עד הסוף. אף אחד מאיתנו אינו יודע את כל התורה ובעולם טכנולוגי מורכב כזה – תמיד ישנן עוד חלופות!!!
האם שווה לנו לפספס אותם? התקציב הוא מוגבל. הרי בהנהלות הארגונים, בוחנים את כל האפשרויות לפני השקעות גדולות מאוד – אז למה שלא ננהג כך גם בהשקעות בינוניות?
אני מציע שימוש בשירות חדש –
Second Opinion
- שירות של קבלת חוות דעת שניה על תכנון פרויקטים בינוניים / קטנים בעולם הסאפ.
- חוות הדעת תינתן על סמך מסמכי התכנון והאפיון הראשוניים, HLV (High Level Design) או Blueprint ראשוני שיסופקו למציע השירות. לא לחכות למסמכי האפיון המפורטים.
- השירות יבוצע בידי מיישמים/מפתחים מומחים בכל תחום, פרילנסרים או שכירים אצל האינטגרטורים. הרעיון הוא להשתמש בניסיון והידע העצומים שהצטברו אצלם.
- אם אנחנו כבר קשורים עם אינטגרטור מסוים ניתן גם להיעזר במיישמים אחרים שלו שלא מכירים את הארגון שלנו.
- השירות יכלול הצעת חלופות נוספות לתכנון המקורי או אשרור שהחלופה שנבחרה היא הנכונה ביותר. גם זה היזון חוזר חשוב!
- השירות צריך להיות מהיר וממוקד – בשאיפה לקבל חוות דעת תוך יום! להערכתי זה ריאלי בגלל שמדובר על מסמכים קצרים והיקף עבודה קטן.
- בהתאם לרוח תקופה זו – השירות יבוצע באופן מקוון ומרחוק. ניתן להיעזר גם בפגישות זום לצורך הבהרות והסברים.
בתקופה מאתגרת זו של עבודה בצל הקורונה אני יודע על מיישמים המוכנים גם לספק שירות כזה בחינם בינתיים לתקופה זו ועד שיוכח שזה אכן מועיל ומשתלם לכל הצדדים.
אני מוכן לספק שירות כזה ולקשר את המעוניינים בכך עם פרילנסרים מובילים.
בהצלחה!
עודד
הבלוג של עודד לקהילת הסאפ בישראל 