התאמה אישית מול התקנת ברירת מחדל

בית » ניהול מחזור חיי מוצר – PLM » התאמה אישית מול התקנת ברירת מחדל

Customization vs. Out Of The Box
התאמה אישית מול התקנת ברירת מחדל

מאת שאול שולנסקי *

שאול שולנסקי

כשניגשים ליישום פרויקט יישום של כלי PLM, תמיד עולה השאלה:
האם להתאים את הכלי המיושם לשיטת העבודה שנבחרה, או להתאים את שיטת העבודה למה שקיים בכלי שנבחר ליישם ?
שאלה זו כבדת משקל, ומשליכה לא רק על פרויקט היישום, אלא בעיקר על עתיד המערכת, על התחזוקה והשדרוגים שיהיו בהמשך.
לשאלה זו אין תשובה בינארית, זה לא תשובה של כן או לא, יש גם תחום ביניים, בכל פרויקט תיבחר דרך פעולה מתאימה לו (FBC).
לרוב הלקוח הישראלי נוטה לגישה של Customization, בשל גישתו הביקורתית, אינו מוכן לקבל את הטיעון ש: "ככה התוכנה עובדת", או "אנשים חכמים עם ניסיון עומדים מאחורי שיטת העבודה המוצעת", ועומדים על כך שהתוכנה תתנהג כמו שהם חושבים שהתוכנה צריכה להתנהג, גם אם זה כרוך בפרויקט תוכנה נוסף.
אתייחס למאפיינים של כל שיטה, יתרונות וחסרונות.

התקנת ברירת מחדל –  OOTB

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

יתרונות השיטה

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

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

Customization

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

המשימות המבוקשות בכתיבה נוספת

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

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

הבעיה בהתאמה אישית (קסטומיזציה) 

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

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

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

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

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

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

לסיכום בעת בחירת אופן יישום פרויקט קח בחשבון:

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

* שאול הנו ראש תחום PLM במטריקס

    מלאו את הטופס ונחזור אליכם





    נגישות