apple-touch-icon-144-precomposed

פיתוח מיזמים אינטרנטיים

מאיזה טעויות כדאי להימנע כאשר מנהלים תחום מערכות מידע?

ריבוי כוח אדם

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

ריבוי מתווכים

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

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

עבודה מול גורמים מרמה גבוה מדי

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

חוסר תיעוד

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

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

ריכוזיות מידע אצל גורם אחד

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

ריבוי משימות וחוסר סדר עדיפויות

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

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

לדעתי נושא התיעדוף הוא פשוט, כאשר מדרגים את המשימות לפי קטגוריות הבאות:

חשוב ודחוף – A, חשוב ולא דחוף – B ,לא חשוב ודחוף , לא חשוב ולא דחוף

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

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

ריבוי תהליכים מקבילים

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

חוסר יכולת למפות את כל התלויות

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

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

בכבוד והערכה רבים!

BusyPlace

לפגישת ייעוץ, ללא עלות וללא התחייבות

התקשר עכשיו
058-4481366

מעוניין לקבל עדכונים מעניינים
 כן
אנו כאן בשבילכם, אל תחכו צרו קשר כבר עכשיו: 058-4481366