רכש IT Procurement

לאחרונה בצעה STKI בדיקה לגבי התנהלות מחלקת רכש IT. מן הברור עולות נקודות אלו:
1. ישנה שונות רבה בין הארגונים לגבי ההתייחסות של רכש IT. בין ארגונים שבהם מחלקת הרכש מעורבת ברמה העסקית (הנושקת לטכנולוגית) מבחינת בחירת ספקים, טכנולוגיות, צורות הטמעה (המשפיעות על עלויות) וכד'. לבין מחלקות אשר אינן מעורבות כלל ואשר מקבלות "טיוטת" רכש כולל מחירים, מועדי הספקה ולעיתים גם תנאי תשלום ובמקרה זה מחלקת הרכש רק מוציאה את ההזמנה בפועל.
2. החלקים הלוגיסטיים – קליטת הציון אינן מטופלים על ידי צוות הרכש אלא על ידי הצוותים המקצועיים אשר מעדכנים במערכת ה- ERP שהתבצעה קליטה.
3. אישור חשבוניות מתבצע על ידי מחלקת הרכש לפי נוהלים קבועים מראש שעיקרם גודל החשבונית. חשבוניות גדולות במיוחד מאשר אף המנכ"ל.
4. בארגוני הרכש קיימים בד"כ שני דרגים לפחות. דרג הקניינים אשר מבצע את המשא ומתן וקובע מדיניות. דרג העזר מסייע בחלקים הטכניים של הוצאת ההזמנה ומבצע את קבלת החשבוניות (הזנה למערכת) ואחראי לאישורים תוך קביעת התהליך המתאים. יש חשבוניות אשר מאושרות על ידי דרג העזר בלבד (לעיתים תוך אישור הדרגים המקצועיים) ויש חשבוניות שחייבות באישור הקניינים ולעיתים כאמור אף אישור דרגי הנהלה בכירים יותר. כלומר רוב נטל אישור החשבוניות מתבצע על ידי כוח העזר.
5. מבחינת כ"א במחלקת הרכש תמונה אפשרית היא ש- 50% מהצוות הוא קניינים ו-50% כוח עזר.

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

ביטוח בחוזה מחשוב - insurance

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

האם לדעתך מקובל לדרוש מהיצרנים\משווקים\יבואנים ביטוח לארועים מסוג זה? ואם כן, האם קיימת חלוקה, למשל - ציוד קצה פטור מהביטוח וציוד מחשב מרכזי וציוד תקשורת חייבים?
על פי הבירור רוב הלקוחות אכן מתייחסים לסוגיה של חבות מעבידים לעובדיהם- אם עובד של קבלן נפצע במהלך העבודות אלו אצל הלקוח – מי שאחראי הוא מעסיקו הישיר ולא הלקוח שהזמין את העבודה. יש תחומים שבהם יש הקפדה מיוחדת לדוגמה בנושאים של "מתח גבוה".
לגבי אחריות נוספת, אצל לקוחות רבים אין התייחסות ספציפית עם זאת איתרתי לקוח שאכן דורש מהספק שהיה אחראי לשורה שלמה של נזקים אפשריים נוספים. לעיתים אף דורשים מהספק ש"יציג פוליסת ביטוח המכסה את האחריות".
להלן ניסוח חופשי של התנאים המופיעים בהסכם הכללי של אותו ארגון:
• לספק יש אחריות על כל אובדן נזק לגוף ולרכוש עקב מעשה או מחדל של או אובדן של הספק.
• מדובר על נזק ישיר (תאונת דרכים שביצע עובד של הספק) או עקיף (בגלל שמערכת ה- CRM לא עבדה הלקוחות איבד X הכנסות).
• יש הגבלה לגובה הנזק (מחיר העסקה או פעמיים מחיר העסקה) פרט לנזקי גוף או נפש או נזק לרכוש ממשי, מוחשי או אישי, או נזק הפרה של קניין רוחני (אם תובעים את הארגון על שימוש ב- open source - אז כל התביעה עוברת לספק) . כלומר יש הגבלה לנזקים עקיפים (אובדן הכנסות) אבל לא לנזקי גוף, נפש, רכוש או קניין רוחני.
• הלקוח גם "ישתף פעולה" עם הספק במידה של תביעה ויעביר לו מידע רלוונטי במידת האפשר.
• הספק צריך להוכיח תוך 21 יום מחתימת ההסכם שיש שהוא מכוסה בביטוח מתאים (יש מקרים שבהם יודעים שלחברה יש פוליסה כזו – לדוגמה IBM).
בארגון המדובר אלו התנאים המופיעים בחוזה הסטנדרטי אבל יש מקרים רבים שבהם לא מתעקשים על כל הפרטים. לדוגמה בתחום PC לא דורשים אחריות כוללת לכל הנזקים (לדוגמה למצב שבו יש שרפה שנגרמה בגלל ה- PC. במקרה כזה הספק יחליף את ה- PC אבל לא יפצה את הארגון על נזקי השרפה). בתחום השרתים\אחסון כן מקפידים יותר גם על סעיפים אלו.

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

שיקולים במדידת זמני תגובה לאתר אינטרנט response time

לאחרונה בדק איתנו אחד הלקוחות את הסוגייה של הגדרת זמני תגובה לאתר אינטרנט חיצוני. כל זאת לקראת יישום הדרישות במכרז עתידי.
ישנם מספר נקודות שיש לשים עליהם את הדעת:
• זמן תגובה של מה? האם שהדף עולה כולו, או שעולה תוכן חלקי? מה קורה בזמן שמחכים לתוכן שיעלה ( כדאי להראות למשתמש ש"משהו קורה"). האם זמן התגובה הוא מקסימלי לכל הדפים או שדורשים שהממוצע יהיה X מילישניות.
• האם מדובר בדף הראשון - שלעיתים לוקח קצת יותר זמן בגלל שזאת הפעם הראשונה שעולות תמונות שנמצאות בשימוש בכל הדפים.
• איפה נמדד זמן התגובה - האם ביציאה מאתר ה- hosting או אצל המשתמש? ואם אצל המשתמש - באיזה סוג חיבור וקיבולת יש למשתמש? אפשר לקבוע שדורשים זמן תגובה של X שניות אצל המשתמש עם תקשורת של 1.5M של ADLS.
• למען הסר ספק. יש לקבוע עם הספק כיצד תתבצע המדידה – האם אוטומטית (רצוי...) ובאיזה כלי. הזוכה במכרז יצטרך לספק גם את כלי המדידה שיהיה ברשות הלקוח.
בד"כ מדובר על ערכים של 2-4 שניות ויותר (תלוי במורכבות הדף והטרנזאקציה) כאשר לדף הראשון (בפעם הראשונה שנטענות התמונות שמלוות את כל האתר) נותנים עוד קצת.

תוספת סטנדרטית לחוזה IT

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

=============

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

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

============

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

דוגמה אישית גם ב- KPI ?

בשנות השמונים עבדתי תקופה קצרה כמלצר חדר אוכל במלון ספורט באילת.
העבודה הייתה קשה ולא החזקתי בה הרבה אולם חוויה אחת זכורה לי הייטב.
היה זה חול המועד פסח, המלון היה בתפוסה מלאה, ובארוחת הבוקר הצטבר תור אנשים נזעמים בפתח חדר האוכל. אנחנו, המלצרים, פשוט לא עמדנו בקצב.
ואז, מי שהצטרף לצוות הוא מנהל חדר האוכל. המנהל הפשיל שרוולים והתחיל לפנות ולערוך שולחנות בעצמו. כולנו קיבלנו "פילפל בתחת" ותוך מספר דקות הדבקנו את הפער, התור נעלם ואיתו השתפר מצב הרוח של האורחים ושלנו.
זה היה שיעור ממקור ראשון לכוח המדהים של דוגמה אישית מצד המנהלים.
גם כעת אני רואה מנהלים רבים אשר נותנים דוגמה אישית לעובדיהם במימדים רבים – התמודדות במצבים קשים, מקצועיות, התמדה ועוד. המנהלים מהווים במצבים מסויימים חלק מהצוות ובאמצעות היותם חלק מהצוות הופכים להיות גורם מוטיווציה ראשון במעלה.
אולם, ישנם מקרים בהם ישנה סטייה מהתמונה האידאלית שציירתי. באחד הארגונים יש מערכת KPI מפותחת להערכת ביצועי העובדים , המנהלים והארגון בכללותו. אולם, מסתבר שכמה ממימדי ה- KPI הנמצאים בשימוש להערכת העובדים לא נמצאים בשימוש להערכת העובדים. בארגון זה מוגדרים מדדים למדידת הבלאי של העובדים (attrition). כמה ימים עבד העובד מעל 10 שעות. כמה פעמים בחודש עבד העובד מעל 5 ימים וכד'.
מדדים אלו מסייעים לארגון לזהות מצבים שבהם עובדים נשחקים וכך נפגעת התפוקה שלהם לטווח הארוך ובסופו של דבר נמצא שמדדים אלו לאורך זמן נמצאים בקורלציה רבה עם עזיבה של עובדים -הפסד גדול לארגון.
אולם כאמור, מדדים אלו שמופעלים כלפי העובדים הזוטרים אינם נמצאים בשימוש ביחס לאוכלוסיית המנהלים. אין מדידה של שעות העבודה המוגזמות או ימי העבודה הרבים כי הם "מנהלים שאמורים אכן לעבוד יותר". בכך יש סתירה לדעתי לעקרון של דוגמה אישית. המשמעות היא שההנהלה הבכירה אינה מקבלת את חשיבותם של מדדים אלו כי אחרת הם היו מופעלים כלפי הארגון בכללותו. אולי יש לצור מדדים מיוחדים למנהלים (אולי "עבודה מעל 11 שעות ביום") אך באופן בסיסי יש להכיל את המדדים גם כלפי המנהלים ובכך לתת דוגמה אישית לחשיבות מדדים אלו.