חפש מאמרים:
שלום אורח
18.08.2019
 
   
מאמרים בקטגוריות של:

   
 

IT בשני חלקים

מאת: עדה מרקמןמיחשוב ארגוני11/06/2012753 צפיות שתף בטוויטר |   שתף בפייסבוק

חלק א: IT איטי

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

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

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

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

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

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

1. מורכבות מיותרת : מנסיוננו כמנהלים וכיועצים , וממחקרים שעורכים גופים שונים לאורך השנים עולה כי במערכות תוכנה ייעודיות, לא יותר מ- 2/3 מה-Features אכן דרושים , ומביאים ערך בתהליך העסקי בו הם תומכים. לעיתים קרובות Feature –ים שפותחו לא רק שלא מביאים ערך אלא גם לא נמצאים בשימוש. המורכבות המיותרת  מונעת שימוש יעיל במערכות, ומגדילה את הצורך בהדרכה והטמעה. זאת בנוסף למאמץ המיותר בתכנון, פיתוח ותחזוקה, מאמצים שניתן היה להשקיע בפעילות אחרת המביאה ערך.  במונחי לין זהו בזבוז המזוהה כ-Overprocessing – לעשות יותר מאשר נדרש להבאת ערך ללקוח. יש סיבות מדוע זה קורה ולא נדון בהן כאן.

2. איכות : שגיאות תכנון ותכנות מהוות בזבוז. לפי מחקר שנערך ע"י אוניברסיטת קרנגי מלון בקרב 13,000 מפתחי תוכנה, מפתח מנוסה ומקצועי מייצר  מעל 100 שגיאות תכנות בכל אלף שורות קוד. כתוצאה מכך חלק ניכר מתקציבי הפרויקטים ומהזמן המושקע בהם – מוקצים לטיפול בתקלות שהם עצמם ייצרו . בנוסף לכמות האדירה של Rework , הולך לאיבוד זמן רב, נוצרים תסכולים ושחיקה, הפרעה ללקוחות ול- Businessוכמובן מאמץ משמעותי מאוד לספק תמיכה טכנית כשמתגלה תקלה. לא רק שחשוב מאוד לגלות ולתקן שגיאות קרוב ככל האפשר למקום היווצרותן, אלא שעלינו למנוע את היווצרותן של שגיאות ואת כניסתן לקוד, כמו גם למנוע את כניסתFeaturesמיותרים לקוד לכתחילה. התופעות האלה ניתנות לטיפול ולצמצום תוך שימוש באחד העקרונות של Lean- Quality at the Source.

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

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

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

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

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

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

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

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

Lean-IT ובכלל זה Lean Software Development מציעים כלים מעשיים להתמודד עם המצב הזה ולשנותו.

חלק ב: עקרונות Lean Software Development

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

Lean Software Development מתחיל בעקרון פשוט : זהה את 20% של הקוד שיספקו 80% מהערך, וספק אותם מהר ככל האפשר. Lean Software Developmentמדגיש תזמון Pullבמקום Push , כאשר מערבים את הלקוח בהגדרת דרישות ובבדיקות בכל איטרציה.

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

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

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

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

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

במקום מפל מים נמשך לאורך זמן עם ניהול פרויקטים קשיח, Lean Software Development מסתמך על איטרציות מהירות (טקטים, ספרינטים) כאשר כל ספרינט מהווה הזדמנות לצוות וללקוח לקבל החלטות בהתבסס על תוצאות הסבב הקודם. כל איטרציה היא מעגל שלם של PDCA – Plan Do Check Actבו פותרים בעיות .

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

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

יתכן ש- Lean Software Developmentהינו תהליך ה-One Piece Flowהמנוסה והמוכח ביותר: חברות כמו Google, שלקוחותיהן בעולם התרגלו  ליהנות מחידושים תכופים ומפתיעים המוטמעים בתוכנה באופן חלק , משחררות גרסאות לעיתים ברמה יומית. מעובדי Google מצופה להקדיש כ-20% מזמנם לחפש רעיונות חדשים בדומה למהנדסי חברת 3M החדשנית. השקעת זמן זו הינה מניע אסטרטגי חשוב המסייע לשיפור המוצר ולגידול בכמות הלקוחות.

מהנדסי Googleעוקבים ברמה יומית אחר דפוסי השימוש של לקוחות במוצר, ומנחים את הפיתוח העתידי על בסיס מידע מוצק אודות Feature –ים ופונקציונליות פופולריים ונחוצים – Voice of the customer – עיקרון נוסף של Lean.

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

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

 





 
     
     
     
   
 
אודות כותב המאמר:

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

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

 
     
   
 

מאמרים נוספים מאת עדה מרקמן

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

מאת: עדה מרקמןמיחשוב ארגוני11/06/12743 צפיות
לפני יותר מ-20 שנה, מחברי הספר "המכונה ששינתה את העולם", גרמו ל"רעידת אדמה" כשהסבירו איך מערכות Lean ישנו את פני תעשיית הרכב. ג'יימס וומאק, דניאל ג'ונס ודניאל רוס ריכזו כוחות על מנת לתעד את בצורה מדוייקת את היתרונות של שיטת Lean שהיתה נהוגה בטויוטה על פני המודל של ייצור המוני שפותח בג'נרל מוטורס והיה נהוג בקרב יצרני הרכב האמריקאים.

מאת: עדה מרקמןמיחשוב ארגוני08/03/12591 צפיות
ארגונים רבים כבר עשו צעדים לאימוץ שיטות עבודה מוכחות לניהול פרויקטים במידה כזו או אחרת ואף רכשו כלי תוכנה ייעודיים. חלק מהארגונים משקיעים בקורסים לניהול פרויקטים וחלק מטמיעים שיטות עבודה אך עדיין קיימים מנהלים ששואלים את עצמם כמה כדאי להשקיע בתחום זה אם בכלל. לעיתים עדיין נשאלת השאלה האם קיים ROI לניהול פרויקטים בצורה מתודית וסטנדרטית. רובנו אוהבים להאדיר את ערכי הספונטניות והמקוריות ומפקפקים בערכה של עבודה "לפי הספר".

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

מאת: עדה מרקמןמיחשוב ארגוני19/02/12528 צפיות
השינויים שחלו בשנים האחרונות בתחום המחשוב אינם מאפשרים עוד עבודה ורטיקאלית ועצמאית. אם בעבר, מתכנתים עבדו מול מערכות מחשוב מרכזיות (MF) וגוף ארגוני אחד הוביל את הפרויקט מתחילתו ועד סופו באופן כמעט עצמאי, או לפחות כמוביל דומיננטי עם תלות מינורית בגופים נוספים, היום המצב שונה

מאת: עדה מרקמןמיחשוב ארגוני19/02/12651 צפיות
ארגונים רבים שמיישמים מערכות SAP מתמודדים עם אתגר צמצום עלות הבעלות הכוללת ((TCO. מסתבר שגם לקוחות מנוסים וותיקים אינם מצליחים להגיע ליעילות תפעולית אופטימלית. בדיוק לשם כך פיתחה SAP כלים ומתודולוגיות שמאפשרים לארגונים לצמצם את עלויות ה-IT לשפר את ה- TCO באופן משמעותי, להתאים את מערכות המידע לצרכים המשתנים, ולהעניק ללקוחותיהם שירות טוב יותר.

מאת: עדה מרקמןמיחשוב ארגוני11/01/12551 צפיות
מימוש ITIL בארגונים מניב מגוון תועלות בהיבטים התהליכים, התפעוליים והתרבות הארגונית. בסופו של דבר, הכל מתורגם לחיסכון תקציבי ניכר", אמרה מרקמן, מנכ"ל משותף ב-BDA, שהייתה מהדוברים בכנס השנתי של itSMF ישראל, הנערך זו הפעם החמישית ● במסגרת הכנס הוענקו פרסים לארגונים שהטמיעו ITIL בהצלחה - אנשי ה-IT באמדוקס, משרד המשפטים וממר"ם.

מאמרים נוספים בנושא מיחשוב ארגוני

מאת: צח סחרמיחשוב ארגוני26/04/172525 צפיות
מרכזיית IP וירטואלית לעסקים בענן - התקדמו לעולם התקשורת החדש ללא צורך ברכישת תשתיות התקדמו למרכזיית טלפונים חכמה בענן, תהנו מכל היתרונות (שרידות, תכונות מתקדמות ועוד) ועדיין תחסכו ממון רב (הקמה מיידית, ללא צורך ברכישת תשתיות יקרות, ברכישת חומרה, הזמנת קווים, עלויות תחזוקה והוצאות מיותרות נוספות

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

מאת: yuval ozמיחשוב ארגוני12/04/15971 צפיות
מאמר שיעזור לכם להבין קצת יותר לעומק מהו שרת וירטואלי ומה הקשר שלו אלינו, למה משתמשים בו ומי משתמש בו

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

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

מאת: MyBusinessמיחשוב ארגוני25/11/141109 צפיות
חשיבות השימוש בתוכנה מקצועית ואיכותית לניהול העסק שלכם והיתרונות הטמונים בכך.

מאת: יונימיחשוב ארגוני03/03/147223 צפיות
מכשיר fax משולב הוא מכשיר המאגד בתוכו את האפשרות לפקסס, האפשרות לצלם, האשרות להדפיס והאפשרות לסרוק. ישנם יתרונות רבים במכשיר כזה כשהראשון שבהם הוא חיסכון בכסף – יותר זול לקנות את הכול במכשיר אחד מאשר לשלם על כל מכשיר ומכשיר בפני עצמו

 
 
 

כל הזכויות שמורות © 2008 ACADEMICS
השימוש באתר בכפוף ל תנאי השימוש  ומדיניות הפרטיות. התכנים באתר מופצים תחת רשיון קראייטיב קומונס - ייחוס-איסור יצירות נגזרות 3.0 Unported

christian louboutin replica