IT כבד, יקר ולא מספיק אפקטיבי – קשור באופן עקבי לשיטות פיתוח קלאסיות

אנו שומעים ממנהלים לא אחת שה- IT יקר, ולא רואים את ההשקעה בו כתורמת ישירות לביזנס.

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

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

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

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

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

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

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

שיעורי ההשקעה ב- IT בארה"ב היו בשנים האחרונות קרובים ל-7% במגזר הפיננסי, וקרובים ל-5% במגזר הבריאות. אלה מייצגים סכומי עתק.

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

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

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

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

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

1. מורכבות מיותרת - מניסיוננו כמנהלים וכיועצים, וממחקרים שעורכים גופים שונים לאורך השנים, עולה כי במערכות תוכנה ייעודיות, לא יותר מ-2/3 מה -Feature- ים אכן דרושים, ומביאים ערך בתהליך העסקי בו הם תומכים. לעיתים קרובות Feature -ים שפותחו לא רק שלא מביאים ערך, אלא גם לא נמצאים בשימוש . המורכבות המיותרת מונעת שימוש יעיל במערכות, ומגדילה את הצורך בהדרכה והטמעה. זאת, בנוסף למאמץ המיותר בתכנון, בפיתוח ובתחזוקה - מאמצים שניתן היה להשקיע בפעילות אחרת המביאה ערך. במונחי Lean זהו בזבוז המזוהה כ- Over Processing קרי לעשות יותר מאשר נדרש להבאת ערך ללקוח.
2. איכות - שגיאות תכנון ותכנות מהוות במונחי Lean - בזבוז. מחקר שנערך על ידי אוניברסיטת קרנגי מלון בקרב 13 אלף מפתחי תוכנה העלה, כי מפתח מנוסה ומקצועי מייצר מעל 100 שגיאות תכנות בכל אלף שורות קוד. כתוצאה מכך, חלק ניכר מתקציבי הפרויקטים ומהזמן המושקע בהם, מוקצים לטיפול בתקלות שהם עצמם ייצרו. בנוסף לכמות האדירה של עבודה חוזרת, הולך לאיבוד זמן רב, נוצרים תסכולים ושחיקה, הפרעה ללקוחות ולביזנס וכמובן מאמץ משמעותי מאוד לספק תמיכה טכנית כשמתגלה תקלה. לכן, לא רק שחשוב מאוד לגלות ולתקן שגיאות קרוב ככל האפשר למקום היווצרותן, אלא שמטרתנו למנוע את היווצרותן של שגיאות ואת כניסתן לקוד, כמו גם למנוע את כניסת Feature -ים מיותרים לקוד מלכתחילה .

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

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

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

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

זה מצב דומה מאוד לאולמות היצור מלפני 50 שנה, ולאתגרים שהניעו את הטרנספורמציה מייצור המוני לייצור ב- One Piece Flow , ב- Lean Manufacturing .

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

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

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

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

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

כותבת המאמר : עדה מרקמן, מנכ"לית BDA
ליצירת קשר: ada@bda-projects.co.il