קטגוריה: ניהול

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

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

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

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

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

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

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

לשון אחר: אין חדש תחת השמש.

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

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

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

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

לכל המקרים מכנה משותף: הנכונות לקבל מורכבות של פרויקטים בתחום מערכות מידע ולקבל החלטות קרות ושקולות.