קטגוריה: ניהול

קטגוריות
מערכות מידע ניהול

מי צריך מנמ"ר

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

  1. מערכות מידע כעבדים או כמרכז עלות – מנמ"ר חלש, הכפוף למנהל (כספים או תפעול), המגיב לדרישות של העסק.
  2. מערכות מידע כנותן שרות פנימי – מנמ"ר חזק, המנהל את מערכות המידע כארגון בתוך ארגון.
  3. מערכות מידע כחלק מההליך הארגוני – מנמ"ר המהווה חלק מתהליךקבלת ההחלטות של הארגון.

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

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

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

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

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

קטגוריות
מערכות מידע ניהול

עצור סיסמה!

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

כיום אני זקן ופראנואידי, אבל אולי מעט חכם יותר:

  • לאנשים יש יותר סיסמאות מסינפסות ((ואני מתיחס גם לאנשים חכמים)). אין סיכוי שהם יזכרו את כל הסיסמאות שלהם.
  • פורצים אינם משתמשים ב-Brute force נגד סיסמאות, זהו בזבוז זמן ומשאבים. רוגלות והנדסה חברתית הם הכלים להשגת סיסמאות.

התוצאות ידועות:

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

אז מה לעשות? כמה כללי אצבע:

  1. להגביל מראש את יכולות המשתמש במערכת (הרשאות על ספריות, תוכנות או מחשבים).
  2. להשתמש רק בפרוטוקולים מאובטחים (SSL לאתרי אינטרנט, SSH להעברת נתונים).
  3. להסיר מהמערכות כל רכיב שאינו חיוני (סרגלי כלים תמוהים למיניהם על הדפדפן).
  4. לחסום את גישת המשתמש כאשר אין לו צורך בגישה (כאשר עובד עוזב את החברה).
  5. ודאו כי מנגנון ניהול הסיסמאות שלכם בטוח (ראיתי מספיק מנגנונים ניהול סיסמאות מבוססי MS-SQL,שסיסמת ברירת המחדל של מנהל המערכת לא שונתה….)

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

קטגוריות
ניהול

RE: RE: RE – רע! רע! רע!

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

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

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

הצעתי להם לחפש בכל תיקיות הדואר היוצא (Sent Items בלע"ז), כל דבר דואר העונה לקריטריונים הבאים:

  1. מתחיל ב-RE: RE: RE
  2. כולל את הביטוי "ענק!"
  3. כולל שניים או יותר סימני קריאה

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

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

כמה לקחים:

  • גם אם קיבלתם את הבדיחה או המצגת האולטימטיבית – חשבו פעמיים לפני שאתם מעבירים אותה הלאה. אם החלטת כי היא ראויה, אולי עדיף להתשתמש באחד מאתרי השיתוף, ולשלוח קישור.
  • התיחסו לנמענים שלכם בכבוד. אל תלחצו Forward ומיד Send. נקו מהדואר את כל שאריות התכתובות הקודמות ופרסומות אתרי ה-WebMail. נסו לפחות להראות כאילו אכפת לכם מהנמענים.
  • הפעילו מעט שיקול דעת לפני שאתם מקישים Ctrl-A על רשימת הכתובות שלכם ושולחים את הדואר לכוווולם.
  • האם אני באמת צריך להזכיר לכם כי לא שולחים לכל רשימת התפוצה תחת TO:?
  • אם הדואר הוא בתוך הארגון, אל תשלחו את הקובץ. שימו אותו במקום משותף ושילחו קישור.

מסר נוסף אותו אני מנסה להעביר בארגונים: Sent Items הוא מקום מיותר. שלחו עותק נסתר (BCC) לעצמכם. כך הוא יופיע בתיבת הדואר הנכנס, ואם הוא חלק מדיון, הוא גם יצטרף לשירשור. כאשר תתייקו את הדואר, גם דברי הדואר היוצא יהיו חלק מהתהליך. יתר על כן, אם אתם עדיין משתמשים בשרותי דואר כמו POP3 (הנפוץ אצל מרבית ספקי האינטרנט), הדואר היוצא יגיע אל השרת, ולא ישאר מיותם עם על הדיסק המקומי.

למרבית הצער, לא מעט תוכנות דואר מתעקשות להשתמש ב-Sent Items. במקרה זה, פשוט נקו אותו אחת לשבועיים או שלושה.

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

קטגוריות
ניהול

סדר שיהיה פה!

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

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

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

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

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

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

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

מוסר השכל, כלים שימושים רק אם משתמשים בהם.

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

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

גם זו דרך.

קטגוריות
ניהול

קוטר!

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

חלק מזה נובע ממי שאני באופן אישי וחלק ממי שאני באופן מקצועי.

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

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

  1. בורות מוצהרת. בדרך כלל באה לידי ביטוי  "אני לא מבין כלום במחשבים".
  2. עוינות. "אתם אנשי המחשבים מסבכים את הכל".
  3. תחרותיות. "אני יודע על מערכת שאתה אולי לא מכיר…"

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

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

יתכן כי אני יכול להיות חביב יותר. אבל אז לא אהיה אני.