ניתוח מול פיתוח Development vs. Design

חברת STKI ערכה מחקר בנושא "פיתוח מערכות תוכנה בארגוני IT". תוצאות המחקר התפרסמו בכנס השנתי שלנו והיוו מחקר ראשון בתחום זה בישראל.
בעקבות שאלות של לקוחות להלן התייחסותנו למאמץ המושקע בניתוח מערכות למול המאמץ המושקע בפיתוח (החל משקף 8) . על פי שאלות של מספר לקוחות, החלק של מנתחי המערכות (ניתוח ועיצוב) במחקרים אחרים גדול יותר מחלקם כפי שהתקבל במחקר STKI. להלן התייחסותנו לשאלה זו:
לקוחות STKI נתבקשו למלא כיצד מתחלק תקציב הפיתוח ב- IT בין מנתחי מערכות, מפתחים, שלב בדיקות וכד'.
ניסוח זה דומה אך לא זהה לשאלה של "כיצד מתחלק תקציב הפיתוח בין שלבי הפיתוח השונים" זאת מכיוון שעל פי הבירור שערכנו בארגונים רבים (למעשה כל הארגונים אתם בצעם את הבירור הנוסף) מסתבר שהחלקים היותר טכניים של העיצוב - Low level detailed design - מתבצעים על ידי צוותי הפיתוח ולא מוגשים על ידי צוותי המנתחים כמקשה אחת. במיוחד בפרוייקטים הקטנים שבהם לא בונים בנפרד אפיון מפורט אלא מעבירים לפיתוח באופן מיידי (לא נתייחס במקום זה האם תופעה זו מבורכת...).
כלומר חלק מפעולות ה"עיצוב" מתבצעות על ידי המפתחים.
נקודה נוספת היא שהחלקים העליונים של האפיון מתבצעים לעיתים על ידי הגוף הדורש שמכיל רפרנטים ברמה גבוהה, תחום BRM – Business Relationship Management, או גוף או"ש (לעיתים אכן יהיו שם מנתחי מערכות אך לא חלק מה- IT) ולכן נקודה זו מעצימה את ההשקעה בפיתוח לעומת הניתוח שמתבצע בגוף ה- IT.

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

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


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

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

תחזוקת תוכנה - SW maintenance

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

בהמשך לבקשתך להלן התייחסותנו לסוגיה של תחזוקת תוכנה.
"תחזוקת התוכנה" – הפעולות שיש לבצע לאחר שהתוכנה עלתה לאוויר – מאגדת מספר משימות:
1. שינויים ושיפורים בתוכנה הקיימת
2. תיקוני תקלות \ באגים
3. שינויים בתוכנה עקב גורמים תשתיתיים לדוגמא עוברים ל- Windows7 וכעת יש צורך לבצע התאמות בתוכנה כך שתעבוד עם Win7. לעיתים ניתן להכניס לקטגוריה זו גם חלק מהשינויים ושיפורים. לדוגמה רוצים לחבר את המערכת ב- web services עם מערכות אחרות (מבלי לשנות את הפונקציונליות העסקית של המערכת).
4. תחזוקה כוללת לעיתים גם "שירות לקוחות" \"הדרכה" הכולל הסבר למשתמשים העסקיים מה בדיוק המערכת עושה (כאמור לאחר תום ההטמעה הרשמית).

ישנם גורמים רבים המשפיעים על המאמץ הנדרש בתחזוקת התוכנה. ביניהם:
1. עד כמה מסמך האפיון התאים לסביבה העסקית
2. עד כמה כל הדרישות במסמך האפיון פותחו ונכנסו לייצור
3. עד כמה הסביבה העסקית משתנה (תחרותית, רגולציה וכד'). יותר שינויים עסקיים משמעותים יותר "שינויים ושיפורים" – יותר תחזוקה. תחלופת מנהלים בכירים בעסק עלולים לגרור שינויים עסקיים ואיתם עליה בתחזוקה.
4. באיזה טכנולוגיה נמצאת המערכת ובאיזה שלב של מחזור חיים טכנולוגי היא נמצאת (לדוגמה מערכת שמסופקת כעת עם windows 7 תדרוש פחות תחזוקה מבחינה תשתיתית מאשר מערכת שמסופקת עם WindowsXP כאשר סביר להניח שהארגון יעבור ל- Win7 עוד שנתיים שלוש).
5. באיזה מידה הארכיטקטורה של המערכת גמישה ומאפשר שינויים.
6. רמת הקריטיות של המערכת.
7. רמת הפיתוח והתעוד של המערכת.
8. מורכבות המערכת ובכמה מערכות היא תלוייה. כי שינויים במערכות שבהם היא תלוייה עלולים להביא לגידול במשימת התחזוקה.
9. קיום מומחה. לעיתים כאשר מומחה במערכת עוזב, צריכים להשקיע יותר ב"תחזוקה" כי קשה להבין מה קורה במערכת.
10. כמה שינויים התבצעו בשנה האחרונה. הרבה שינויים יגררו יותר "תיקון תקלות" בשנה אחריה.
11. ה- SLA שנדרש מהמערכת מבחינת זמינות. כאשר המערכת צריכה להיות מאוד יציבה וזמינה 24 שעות – המשמעות היא שעלות התחזוקה גבוהה יותר כי גוף הפיתוח צריך להחזיק צוות בכוננות. דבר שמעלה את עלות התחזוקה.

לסיכום, ישנם גורמים רבים העשויים להשפיע על עלות התחזוקה כאשר שלושת הדרישות הראשונות הן המשפיעות ביותר בד"כ בעלות התחזוקה (דרישות הקשורת ישירות ל"שינויים ושיפורים") ולכן ישנה שונות עצומה בעלות זו.
עם זאת, בתעשיית התוכנה מדברים בדרך כלל על מספרים של 15% עד 20% ממחיר רכש התוכנה\פיתוח הפרוייקט – לשנה. ישנן סיטואציות בהן מספרים אלו יהיו גבוהים הרבה יותר במקרים לדוגמה שקוצצה תכולה מהאפיון המקורי ולכן התכולה המקורית נכנסת תחת "שינויים ושיפורים". ישנם סיטואציות בהן מספרים יהיו נמוכים משמעותית – האפיון תאם את המציאות העסקית, לא היו שינויים בסביבה העסקית, כל התכולה פותחה באיכות טובה וכד'.
הבסיס לחישוב התחזוקה הוא סך כל מה שהושקע בפרוייקט וזאת מן הטעם שנדרשת תחזוקה (תיקון תקלות, עדכונים טכנולוגיים או מנהלתיים, התאמות לשינויים העסקיים) גם להשקעות שאינן פיתוח תוכנה גריידא.
אנא חזור אלינו במידה ותזדקק למידע נוסף או להבהרות,

מאמר מצויין - חבילות תכנה – כיצד להגדיל את הסכוי ולהקטין את הסכון

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

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

להתחיל מכבד לקל

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

המאמר נמצא בקישור המצ"ב  וניתן להורדה דרך קבוצת הקשר ב-  docsNtalks (ללקוחות STKI).

פיתוח מערכות בבית מול חבילה מול מיישם חיצוני

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

· מספר לקוחות דיברו על העדפה כללית של תוכנות מדף על פיתוח עצמי כאשר באופן תמידי יש התלבטות בנושא זה. חלק מהארגונים דיברו על זה שבגלל של-business יש דרישות ספציפיות הדבר מחייב הליכה של best of breed. כלומר מדובר על שילוב של תוכנות מדף עם מערכות שמפותחות בבית.
· לגבי תוכנות מדף, לקוחות דיברו על כך שלעיתים קשה לקבל תמיכה של 24*7 מחברות אזרחיות. דבר נוסף בעייתי הוא שאם לארגון יש סטנדרטים מוגדרים של תשתיות (כמו פלטפורמות, מערכת הפעלה, גיבוי נטור) ואבטחת מידע, למיישמי החבילה או אפילו לייצרן , אין פתרונות מתאימים או ידע מספק.
· לקוח שמשתמש בצורה אינטנסיבית בחבילת ERP דיבר על כך שהחבילה עונה על רוב הצרכים הארגוניים ואם יש חריגים אז מפתחים, אבל מה שמעקב לעיתים פרויקטים או גורם לקשיים בייצור זה ממשקים בכל מה שקשו לתהליכים שהם cross applications.
· לקוח בעל חבילת ERP מאוד ותיקה ומאוד מקוסטמת דיבר על כך שלמרות שזאת מערכת קנויה- האנשים בחוץ (כלומר בעלי מקצוע בחבילה זו) לא ממש מכירים את המערכת הספציפית שנמצאת בארגון ולוקח די הרבה זמן "להכניס אותם לעניינים" (כאמור, למרות שזו חבילת ERP מוכרת) בגלל ההתנהגות העסקית השונה שקוסטמה.
· מסקנה של אחד הלקוחות אשר החל ביצוע של תהליך של החלפת מערכת core system באמצעות פיתוחה מחדש בטכנולוגיה חדשה (פרויקט שבסופו של דבר לא הסתיים בצורה מוצלחת) היא שעדיף לא להחליף מערכות legacy כבדות בצורה מלאה. מה שרצוי זה להחליף את מערכת ה-Legacy בצורה הדרגתית תוך ביצוע של ניהול סיכונים צמוד. כלומר לא "זבנג וגמרנו" כי אז הולך לאיבוד המון ידע וקשה להתחרות עם מערכת שנבנתה עם השנים.
· לקוחות דיברו על הוצאה של פרויקטים לפיתוח מחוץ לארגון כאשר חלק מהארגונים מכתיבים למיישם את כלל הטכנולוגיות המעורבות כאשר חלק מכתיבים רק דברים כמו אבטחת מידע, קישוריות ותשתיות (כמו DBMS).
· לקוח שמבוסס על אחת מחבילות ה- ERP ציין שלמרות הניסיון להתרכז כמה שיותר בחבילה הם מגלים שחייבים להשתמש בחבילות עסקיות שהן צד שלישי ולכן הקישוריות המשופרת של חבילת ה- ERP מאוד עוזרת להם בשילוב המערכות. אבל השילוב של מערכת נוספות גורם לארגון להקדיש משאבים רבים יותר לכל הנושא של בקרה וזאת מכיוון שהכלים המובנים בחבילת ה- ERP שטובים מאוד בסביבת ה- ERP כבר לא מספיקים יותר.
· מספר לקוחות מבססים את מערכת הליבה שלהם על חבילה שנרכשה בזמנו אבל הקוד נמצא אצל הלקוח וכבר זמן רב ישנו קיסטום מהותי של הקוד עד למצב שהמערכת היא כמעט "כמו שפותחה בבית".

STKI – במודל זה מספר יתרונות ובהם העובדה של מתחילים לפתח מאפס אבל מצד שני מכיוון שהקוד נמצא אצל הלקוח הוא מאפשר קיסטום מיטבי ללא צורך להיות תלויים בספק, לא תלוי ב"תום מועד תמיכה" וכד'. מצד שני מודל זה מבחינה טכנולוגית משאיר את המערכת בתצורה קיימת ולא מכליל שינויים טכנולוגיים (כמו תמיכה ב- Web Services) שמתקבלים במוצרי מדף.
מעבר לכך הנושא של פיתוח מערכות core business בבית ב- outsroucing או רכש של חבילות הוא נושא אסטרטגי שמטופל ב- STKI גם על ידי המנכ"ל ד"ר ג'ימי שוורצקופף וגם על ידי האנליסטית הבכירה עינת שמעוני.