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

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

מגמות רכש תוכנה: מרכישה לניהול מחזור חיים

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

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

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

FinOps נכנס גם לרישוי תוכנה

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

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

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

אבטחת מידע הופכת לקריטריון רכש מרכזי

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

במסגרת הבדיקה יש לבחון לא רק הצהרות כלליות של היצרן, אלא את יכולות הבקרה שנדרשות בסביבה שלכם. האם קיימת תמיכה ב-MFA? האם ניתן ליישם SSO ולבצע Provisioning ו-Deprovisioning אוטומטיים? האם יש Audit Log שניתן להעביר ל-SIEM? האם ניתן להגדיר הרשאות לפי תפקיד, להפריד בין סביבות ולחסום גישה לפי מדיניות? בתוכנות גישה מרחוק, כדאי לבחון גם ניהול מכשירים מורשים, אישור משתמש קצה, הקלטת סשנים ומנגנוני מניעת גישה לא מבוקרת.

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

Consolidation: פחות ספקים, פחות נקודות עיוורון

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

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

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

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

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

בכל סקירה רבעונית כדאי לענות על ארבע שאלות:

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

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

התאמת הרישוי לשינויים בכוח האדם

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

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

איך בונים תהליך רכש שניתן להגן עליו

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

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

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

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