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

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

למה ימי רישוי נותרים משנים את תקציב הרכש

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

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

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

החישוב הבסיסי של חיוב יחסי

הנוסחה הפשוטה היא:

`עלות שנתית לרישיון × מספר רישיונות נוספים × (מספר הימים הנותרים / מספר הימים בתקופת המנוי)`

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

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

תכנון תקציב רכש לתוספת תוכנה לפי ימי רישוי נותרים

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

1. מאמתים את בסיס הרישוי הקיים

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

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

2. מפרידים בין צורך קבוע לצורך זמני

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

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

3. מחשבים את העלות בשתי שכבות

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

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

4. בודקים עלויות עקיפות ותלות ברישוי

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

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

מתי לא כדאי להמתין לחידוש

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

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

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

טעויות שכדאי למנוע כבר בבקשת הרכש

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

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

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

תהליך עבודה קצר שאפשר להטמיע

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

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

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