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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. מיפוי תהליכי עבודה קיימים מול תהליכי עבודה רצויים: קשה עד בלתי אפשרי להשוות את קפיצת המדרגה בין מערכות מידע בארגון, לשידרוגים המוכרים לנו מהמחשב הביתי, כמו למשל מעבר מ-וורד 2010 לוורד 2013 או מחלונות 7 לחלונות 8. בניגוד למערכות הביתיות, במערכות ארגוניות לא מדובר רק על תוספת פיצ'רים או שינויים במימשק הגרפי, אלא על שינוי מהותי בתהליכים שאותם מנהלת המערכת. למשל, תהליך מכירה שהיה בנוי בדרך מסויימת, הולך להתנהל מהיום אחרת.

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

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

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

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

אולם פנטזיות לחוד ומציאות לחוד.

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

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

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

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

תמי זיתן היא מנכ"ל משותף ב-IT Solutions