תחום השליטה והבקרה הוא אחד התחומים הבעייתים בתחום מערכות המידע. כאמור בפוסט קודם בתחום זה נכשלים יותר פרוייקטים מבכל תחום אחר במערכות המידע. מעבר לכך בניה של פרוייקט מחייבת בחירה בין תחומי כלים רבים שקימים בתחום. כפי שציינתי במצגת שהעברתי בכנס השנתי שלנו, החל משקף 122 ישנם בתחום טכנולוגיות סטנדרטיות (AGENTS שמדווחים למרכז), כלים לחויית משתמש, כלים המוגדרים כ- Transacation Management המפעילים Sniffing מתוחכם, כלים המוגדרים כ- APM - Application Performance Management , כלים שאני מגדיר בקטגוריה "ספציפית" (לדוגמה כלים לתחום JAVA , תחום רשתות תקשורת, תחום SAP , מסדי נתונים וכד') ועוד.
באיזה טכנולוגיה יש לבחור? כל טכנולוגיה בתחום מציעה את עצמה כ"טכנולוגיה האולטימטיבית" לתחום.
הנקודה היא שעל הארגון להגדיר בצורה מדוייקת מה הוא רוצה להשיג מפרוייקט זה. מדוייקת אינה להצהיר הצהרה "המערכת תאתר תקלות בארגון" כי אמירה זו כללית מידי. האם תקלות בתחום התשתיות? האם תקלות בעולם האפליקטיבי\עסקי? האם תקלות ברמת המשתמש הסופי? כל בחירה כזו משליכה על הפתרון המתאים. גם אמירה "תגלה תקלות בעולם האפליקטיבי \עסקי" היא אמירה כללית מידי.
ולכן, לשם הגדרה מדוייקת של מטרות הפרוייקט אנו ממליצים לעבור על התקלות המהותיות שהיו בארגון ולקבוע מה אמורה מערכת שליטה ובקרה לבצע או יותר נכון כיצד מערכת השליטה והבקרה הייתה אמורה לטפל בין הייתר בגלוי העובדה שיש תקלה, מניעה מוקדמת, מציאת הגורמים לתקלה, טיפול טוב יותר בתקלה לאחר שהתרחשה וכד'.
במכרז יש לציין גם כיצד יש לתפעל את המערכת במובן של שמירה על עדכניות ורלוונטיות. מה יהיו המשאבים לתחזוקת המערכת וכיצד תתבצענה פעולות התחזוקה.
רק תהליך כזה יכול לכוונן את הארגון למטרות ספציפיות בתוך האלטרנטיבות הרבות שקיימות בתחום. תהליך כזה מניח (ובצדק) שבניית סביבה לשליטה ובקרה הוא תהליך מתמשך ולא ניתן בשלב אחד למפות את כל הנקודות העתידיות.
אין תגובות:
הוסף רשומת תגובה