ביקרתי שני לקוחות שונים מאוד לאחרונה, היו להם בעיות שונות מאוד וגם הפתרונות שהצעתי להם היו מאוד שונים. אבל היה דבר אחד שהיה משותף לשניהם, זה ששניהם עכבו את התחלת השיפורים שהם ידעו שנדרשים מהם משום שהעלויות והסיכונים היו גבוהים מדי. במקום זאת, הם לא עשו דבר, וכך נתנו לבעיותיהם להמשיך באין מפריע.
עבור שני לקוחות אלה, הפתרון היה מאוד דומה. שניהם היו צריכים "להתחיל מהיכן שאתה נמצא", "לשמור את זה פשוט" ו "ולהתקדם בצורה איטרטיבית", ממש כמו ב Agile, אלה הם שלושת העקרונות המנחים לאנשי ITIL, בינם לבין עצמם הם מעודדים מנהלי שירות IT לאמץ גישה זריזה לפתרון בעיות, במקום לקחת על עצמם פרויקטים גדולים ומסוכנים ויקרים לניהול שירותי IT (ITSM).
אם גם אתה צריך מקצה שיפורים שנראה יקר מדי, או מסוכן מדי, אז כדאי לך לקרוא את המשך הבלוג כדי להבין מאיפה להתחיל.
ארגון גדול עם בעיה גדולה
אחד הארגונים בהם ביקרתי הוא ארגון גדול מאוד. הוא מספק שירותי תמיכה ללקוחות חיצוניים רבים בכל רחבי העולם, ויש לו המון עמדות שירות. חלק מעמדות השירות הנם ייעודיים ללקוח בודד, ואחרים קיימים על מנת לתמוך בלקוחות רבים, וחלקם עבור משתמשים פנימיים. חלקם מספקים כניסה ושיגור בלבד, ואחרים מספקים תמיכה ברמה 1 בנוסף. בעוד שרבים ממוקדי השירות משתמשים באותו כלי ITSM להתחברות וניהול תקריות, ישנם לא מעט כלים אחרים בנוסף.
כמעט כל תקשורת הלקוחות, עבור כל מוקדי השירות השונים, מתקיימת באמצעות טלפון. הארגון רצה לעבור לערוצים יעילים יותר, למשל: תקשורת מבוססת צ'אט בפורטל אינטרנטי בשירות עצמי, אבל מכיוון שהחברה היא כל כך גדולה, עלויות היישום תהיינה עצומות. מחלקת ה- IT, למעשה, זיהתה כלי שיכול לספק צ'אט עבור כל הסביבה המורכבת שלהם, אבל הם לא יכלו להיות בטוחים כי פרויקט יישום בסדר גודל כזה ירוץ בצורה חלקה או שהתשואה תצדיק השקעה כל כך גדולה, והם לא יכלו להשיג את המימון הנדרש לכך.
כאשר שוחחתי עם מחלקת ה- IT, הפתרון לבעיה שלהם התברר. במקום לנסות ליישם צ'אט לכל המשתמשים שלהם, מה שיהיה פרויקט מאוד גדול ויקר, הם יכולים להתחיל מהמקום בו שהם נמצאים, להתחיל בקטן, ולגדול בצעדים קטנים.
למשתמשים של הארגון כבר יש כלי התומך בצ'אט, אם כי הוא לא משמש כיום לתמיכת IT. אז זה יהיה קל למדי עבור ה- IT להתחיל שם.
הנה מה שהם יכולים לעשות:
למצוא קבוצה ניסיונית קטנה של משתמשים ולהציע להם להשתמש בכלי הצ'ט הקיים כדי לספק להם תמיכת IT. לנטר בקפידה כדי לחשוף בעיות בהלפדסק או אצל המשתמשים, ולפתור אותן לפני שגדלים ועוברים לתמוך בעוד משתמשים פנימיים. בסופו של דבר מחלקת ה- IT יגיעו להבנה בנוגע להיקף היכולות של הכלי הזה בסביבתם, אבל עד אז הדברים הבאים כבר יקרו:
• יזוהו ויפתרו הרבה סוגיות הנוגעות לאיך דלפק השירות עובד בעת טיפול מבוסס אינטראקציות צ'אט.
• יהיה ברור אילו סוגי אירועים מטופלים בצורה הטובה ביותר על ידי צ 'אט, ואילו סוגים מנוהלים טוב יותר באמצעות הטלפון או באמצעות ערוצים אחרים.
• יגלו מהו סוג התקשורת והתמיכה שעובד הכי טוב כדי לעודד משתמשים לעבור משיחות טלפון לצ'אט.
• יאספו נתונים על כמות השיחות שכל תומך יכול לנהל באמצעות צ'אט, וכמה זה יכול לחסוך אם מיישמים את זה על הארגון כולו.
ליישום הדרגתי זה של תמיכה מבוססת צ'אט יהיה סיכון נמוך מאוד, וזה לא כרוך בעלות רבה כיוון שמדובר בכלי קיים ומוכר. עד שמחלקת ה IT תתקדם ללתמוך כך במספר רב יותר של משתמשים פנימיים הם יידעו אם יישום מלא באמצעות כלי קיים זה יהיה השקעה חסכונית, והם גם כבר ילמדו מה הם צריכים לעשות כדי להבטיח הצלחה. אם הם ירצו ללכת על כלי חדש ויקר, זה ייתן להם כל מה שהם צריכים כדי לקחת מזה תובנות (Business Case) עבור השלב הבא.
ארגון קטן עם בעיות אבטחה:
הארגון האחר שבקרתי בו הוא הרבה יותר קטן. יש להם רק שני צוותים של עובדים במוקד השירות בתוך הבית שלהם, הנתמכים על ידי מנהל אשר מבצע תפקידים אחרים גם כן. יש להם כמה אלפי משתמשים במספר קטן של משרדים. הם מתקשים לנהל בקרת גישה למשתמש.
כאשר משתמש חדש מצטרף לארגון, הם שואלים איזו גישה הוא צריך, ולאחר מכן מעניקים לו גישה פרטית ליישומים ונתונים ספציפיים. כשאנשים מחליפים עבודה או עוזבים את הארגון, קשה למצוא את כל הרשאות הגישה שהוענקו להם, ולכן אלה נותרים לעתים קרובות כפי שהיו – וזה יוצר סיכון ביטחוני משמעותי.
מנהל התמיכה ידע שהפתרון לבעיה שלהם היה לעבור לבקרת גישה מבוססת תפקידים (RBAC), שבה כל זכויות הגישה מוענקות לפי תפקידים, ולאחר מכן התפקידים האלה מוקצים למשתמשים. אבל לא היה שום ניסיון להגר ל RBAC בגלל הסיכונים הכרוכים בכך. לפעמים דברים משתבשים אפילו במהלך ההגירות המתוכננות ביותר, וזה יכול לגרום לסיכון ועלויות משמעותיות לעסק.
הפתרון עבור לקוח זה היה גם לעשות את השינוי בשלבים. במקום לנסות לשנות הכל בעת ובעונה אחת, הארגון יכול להתחיל מהמקום בו הוא נמצא , להשאיר את זה פשוט, ולעשות את השינוי בהדרגתיות, צעד אחד בכל פעם.
הנה מה שהם יכולים לעשות:
בפעם הבאה שעובד חדש מצטרף לחברה, להעניק לו את כל זכויות המשתמש שצריך לתפקיד החדש שנוצר, ולאחר מכן להקצות תפקיד זה למשתמש החדש. זה צריך להיות ללא השקעה נוספת וללא סיכון גבוה יותר מאשר הסיכון שיש בדרך כלל במתן גישה מתאימה למשתמש חדש. אחרי שבטוחים שהתפקיד עובד היטב, ולא נדרשים לבצע שינויים כלשהם, אפשר להמשיך להעביר משתמש קיים אחד לתפקיד, ולהסיר את הזכויות הנוכחיות שיש למשתמש. שוב, זה כרוך רק בסיכון קטן, והשינוי יכול להתבטל בקלות אם צריך. לאחר מכן, אפשר להמשיך ולהוסיף כמה משתמשים בכל פעם. ברגע שבטוחים שלא צפוייות להיות בעיות, אפשר להעביר את כל האחרים שאמורים להיות מוקצים לתפקיד זה. כאשר נוצרת ההזדמנות, ליצור תפקיד שני, ולהעביר משתמשים באותה דרך הדרגתית, בסיכון נמוך.
גישה זו אומרת שייקח זמן רב למדי כדי לעבור לחלוטין מהמצב הקיים, ליישום RBAC מנוהל היטב. אבל השיפור האחד שאתה יכול להבטיח שלעולם לא יפסיק הוא זה שאתה חושב שזה מסוכן מדי להתחיל מלכתחילה. על ידי התחלה מהיכן אתה נמצא, השמירה על הפשטות, ההתקדמות הדרגתית, השיפור שהחברה הזו רוצה בסופו של דבר יושג, עם סיכון קטן, וללא צורך בפרויקט גדול שיגביל את זמינות צוותי התמיכה לזמן ממושך.
סיכום
ארגונים רבים משתמשים בפיתוח תוכנה זריז (Agile) כדי להפחית את הסיכון ולהאיץ את זמן היציאה לשוק. אותם הרעיונות חלים באופן שווה גם ב ITSM. כמעט כל שיפור ITSM יכול להתבצע בצורה זריזה, באמת אין שום צורך בפרויקטים ענקיים ויקרים לשיפור ITSM.
אם אתה דוחה שיפורים שאתה יודע שאתה צריך, בגלל העלויות והסיכונים, אז למה לא לחשוב על איך אתה יכול "להתחיל מאיפה שאתה", "לשמור את זה פשוט" ו "להתקדם באיטרטיביות"?
תרגום מאנגלית ( מאמר מקורי מאת סטוארט ראנס )
