מדוע נכשלים פרויקטים של שליטה ובקרה?

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

תחום השליטה והבקרה הנו תחום המועד לפורענות ולכישלון, יותר מתחומים אחרים בתחום ה- IT למרות שתחום זה הנו תחום בשל יציב ואשר טכנולוגית אינו מורכב. באופן עקרוני יישום פרוייקטים מסוג זה מתבצעים על ידי הצבה של agents ברכיבי המחשוב השונים אשר מדווחים למרכז נתונים חיוניים (האם השרת עובד, האם יש מקום בדיסק, האם ביצועי התקשורת סבירים וכד'). בשנים האחרונות ישנה נטייה גם ליצור "מפות עסקיות" של רכיבי המחשוב השונים.
הסיבה החמקמקה לכישלונות בתחום זה קשורה לאופיו הייחודי של הפרוייקט.
באופן טבעי, מוטל עומס רב על צוותי ה- IT השונים. ולכן, לעיתים תכופות, צוותי ה-IT שאחראים לתחזוקת הפרוייקטים אינם יכולים לבצע את כל שנדרש מהם בצורה מלאה ולכן הפרוייקט נפגע בצורה חלקית. כך למשל, אם במידה וצוות הממשקים קיבל תפקיד נוסף, ולכן משקיע 5% פחות מזמנו בטיפול השוטף בממשקים, הרי ש- 5% מפרוייקט הממשקים נפגע. באופן ברור הצוות יכוון את הפגיעה בממשקים הפחות חיוניים. כנ"ל הדבר גם בפרוייקטי IT אחרים כגון CRM, ERP, אחסון ועוד. ואולם, בתחום השליטה והבקרה, המצב שונה בתכלית. אם צוות השליטה והבקרה עמוס, ולכן משקיע בתפקידו פחות מהרצוי, אפילו ב- 5%, הרי שלאחר תקופת זמן של מספר חודשים ישנה פגיעה ב- 100% מתפקוד מערכת השליטה והבקרה. זאת מכיוון שבמידה ואפילו שינויים מעטים במערכות הייצור אינן מעודכנות לסביבת השליטה והבקרה (לדוגמה, התווסף שרת חדש, לדוגמה, הוחלפו שני routers לדוגמה השתנה מספר IP וכד') הרי שהחיוויים במערכת השליטה והבקרה אינם אמינים, משתמשי הפרוייקט אינם מאמינים למערכת ולכן יעדכנו אותה פחות, ותוך תקופה לא ארוכה, ישנה התמוטטות מוחלטת של כל פרוייקט השליטה והבקרה.
בארגוני IT לא גדולים, צוות השליטה והבקרה מונה אדם אחד (או אפילו לא משרה שלמה) וכאשר אותו אדם לא נמצא בעבודה או קיבל תפקיד נוסף ולכן לא יכול לבצע את כל העדכונים, הרי שהדרך להתמוטטות סביבת השליטה והבקרה כמעט מובטחת.

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

אין תגובות: