CSP Networks
מתי ארגון באמת צריך יועץ טכנולוגי בלתי תלוי?
מדריך מעשי לארגונים: מתי נכון לערב יועץ טכנולוגי בלתי תלוי, מה התוצרים שצריך לקבל ואיך להפריד בין צורך, ארכיטקטורה ובחירת ספק.
ארגון לא צריך יועץ טכנולוגי בכל החלטה. הצורך בייעוץ בלתי תלוי מתחיל כאשר ההחלטה מורכבת, קיימות כמה חלופות לגיטימיות, נדרש מכרז או שהטעות עלולה להשפיע על הארגון למשך שנים.
שירותים הקשורים לנושא
- ייעוץ אסטרטגי וארכיטקטורה טכנולוגית - ארכיטקטורת יעד, מפת דרכים, ניתוח חלופות, סיכונים והצדקת השקעה לפני פרויקט משמעותי.
- מכרזים טכנולוגיים וליווי רכש - דרישות מדידות, מנגנוני הוכחה וקבלה, SLA, מודל תמחור, מטריצת השוואה וליווי הבחירה והיישום.
- ממשל, מבנה ותהליכי IT - בחינת מודל ההפעלה של מערך ה־IT לפי עקרונות COBIT ו־ITIL: אחריות, תהליכים, בקרה, שירות ומדדים.
כאשר הבעיה עדיין אינה מוגדרת מספיק
בפרויקטים רבים מתחילים מהר מדי משאלת המוצר: איזה יצרן, איזה דגם, איזה ענן או איזה פתרון אבטחה. אם הצורך עצמו עדיין אינו מוגדר, גם השוואת המוצרים מתחילה מנקודת מוצא לא נכונה.
יועץ טכנולוגי בלתי תלוי אמור לעזור לנסח קודם את הבעיה: מה הארגון רוצה להשיג, אילו מגבלות קיימות, מה קריטי ומהם הקריטריונים שלפיהם ניתן יהיה למדוד הצלחה.
כאשר קיימות כמה חלופות ארכיטקטוניות
הצורך בייעוץ גדל כאשר אין תשובה אחת ברורה: תשתית מקומית, מתקן אירוח, ענן או Hybrid; החלפת רשת מלאה או שדרוג הדרגתי; אתר DR נוסף או שירות חיצוני.
במצבים כאלה צריך לבנות חלופות על בסיס אותן הנחות ולהשוות ביצועים, זמינות, אבטחה, תפעול, גמישות ועלות כוללת.
כאשר הספק שמציע את הפתרון הוא גם מי שמגדיר את הצורך
ליצרנים ולאינטגרטורים יש ידע מקצועי חשוב, אך הם פועלים מתוך סל הפתרונות שהם מייצגים. זה טבעי. הבעיה נוצרת כאשר אותו גורם גם מגדיר את הדרישות וגם מציע את המוצר שמממש אותן.
בפרויקט משמעותי כדאי להשאיר את הגדרת הצורך, הארכיטקטורה והקריטריונים אצל גורם שמייצג את הארגון, ואז לאפשר לספקים להתחרות על בסיס דרישות אחידות.
כאשר ההחלטה תשפיע לשנים
רשת, Data Center, סביבת ענן, ארכיטקטורת סייבר או מודל DR אינם החלטות שמחליפים לעיתים קרובות. אחרי השקעה בציוד, רישוי, תהליכים והדרכה, עלות השינוי יכולה להיות גבוהה.
לכן חשוב לבדוק מראש קיבולת, תמיכה, EOL, מודל רישוי, תלות בספק, יכולת הרחבה ועלות יציאה.
כאשר נדרש מכרז או תהליך רכש תחרותי
מכרז טכנולוגי אינו רשימת ציוד. הוא צריך להגדיר תוצאה נדרשת, תנאי סף, דרישות פונקציונליות וטכניות, SLA, מודל תמחור, מנגנוני הוכחה וקריטריונים להשוואה.
כאשר המסמך בנוי נכון ניתן להשוות בין הצעות שונות. כאשר הוא נכתב סביב מוצר מסוים או ברמת פירוט לא עקבית, ההשוואה הופכת כמעט בלתי אפשרית.
מה צריך לקבל מיועץ טכנולוגי
- מיפוי מצב קיים והנחות יסוד.
- הגדרת דרישות עסקיות, טכנולוגיות ותפעוליות.
- חלופות ארכיטקטוניות ולא רק רשימת מוצרים.
- השוואת סיכונים, ביצועים, תפעול ועלות כוללת.
- מסמכי תכנון, מפרט או RFP לפי הצורך.
- קריטריונים למדידה, קבלה ובדיקת יישום.
מתי דווקא לא צריך יועץ חיצוני
כאשר הצורך קטן, הסיכון מוגבל, הצוות הפנימי מכיר היטב את הטכנולוגיה ואין מחלוקת אמיתית בין חלופות, אפשר בהחלט לבצע את ההחלטה בתוך הארגון.
ייעוץ חיצוני צריך להוסיף ערך במקום שבו חסרה נקודת מבט אובייקטיבית, עומק ארכיטקטוני או מתודולוגיית השוואה.
השורה התחתונה
יועץ טכנולוגי בלתי תלוי אינו תחליף לצוות ה-IT ולא לספקים. תפקידו הוא לעזור לארגון לקבל החלטה טובה יותר לפני שהכסף והארכיטקטורה כבר נעולים.
הערך המרכזי נוצר כאשר מפרידים בין הגדרת הצורך, בחינת החלופות ובחירת הספק.