ERM - באזוורד קטן לתחום גדול

מאמר שכתבתי על נושא ניהול סיכונים ארגוניים (Enterprise Risk Management) פורסם בדהמרקר:

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


• "ניהול סיכונים = הסתכלות על כל תחום עסקי דרך עדשת הסיכון". במצגת משותפת של אורקל וKPMG, עלה כי גישת ה enterprise risk management כיום אומרת שניהול סיכונים אמיתי הנו אספקט שקיים בכל פעולה, יוזמה עסקית, והחלטה אסטרטגית. לכל צעד עסקי מתלווה סיכון, אותו יש לנהל ולקחת בחשבון. לדוגמה, אם חברה רוצה להוציא קמפיין שמדגיש קו מוצרים בעלי אופי חדשני, אחד הסיכונים הוא שהציבור לא יאהב את זה כי הוא יראה בכך סטייה מקו מוצרי העבר אותם הוא אוהב. פילוח הלקוחות כדי להבין עבור מי מקהל הלקוחות צעד זה מהווה סיכון גדול מדי כרוך בעלות נוספת. כלומר, התמודדות עם ה"סיכון" הזה כרוכה בעלויות נוספות, מה שאומר פחות רווח עבור אותה פעילות שיווקית. אם החברה הדביקה תג ROI מסוים ליוזמה זו, הרי שכעת עליה להתאים אותו בהתאם למשמעויות הסיכונים הכרוכים בה. אם ניקח בחשבון את העובדה שרוב הארגונים בישראל אינם מבצעים תהליכי ROI כ"דרך חיים", התאמת הרווחים הצפויים העתידיים ליוזמה מסוימת בשל הסיכון הכרוך בה הנו תהליך עדיין די נדיר במחוזותינו. המסר: כל יוזמה עסקית בארגון צריכה לענוד עדשת סיכון מעליה.


• מי פה מנהל את הסיכון? סיכונים תמיד היו ותמיד היה צורך לקחת אותם בחשבון. ההבדל הוא שכיום ארגונים יותר מודעים לצורך לנהל אותם, והבדל נוסף חשוב - בעבר לסיכון לא ממש היה OWNER, כיום מדברים הרבה על ניהול סיכונים / Risk Governance. אבל מי אחראי על תחום כל כך רחב – ניהול סיכונים בכל הארגון שכוללים סיכונים שקשורים בשוק, סיכונים משפטיים, סיכונים פיננסיים, תפעוליים ועוד? בארגונים כמו בנקים שבהם RISK משולב הלכה למעשה כבר בתוך תהליכים התפעוליים יש מנהל מוגדר. בארגונים אחרים אחריות זו משולבת בתוך מחלקות שונות (משפטי, תאימות לרגולציה... עד הרמה האסטרטגית) וברובם אין מנהל סיכונים ארגוני.


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


• "איפה הROI?" היום מבקשים ROI גם על יוזמות ERM וכבר לא מסתפקים רק ב risk management for the sake of risk management (כלומר, אין לנו ברירה ואנחנו חייבים לעשות פרויקט ניהול סיכונים). אין ספק שנקודה זו תהיה מאתגרת במיוחד עבור ארגונים ישראליים וייקח זמן עד שנדבר על פרויקטי ERM במונחי ROI.


• "החיבור החדש: ניהול סיכונים + ניהול ביצועים". בעולם ניהול הביצועים / balanced scorecard כיום טוענים כי לכל KPI צריך להיות אינדיקטור של סיכון. זה ה balance החדש של עולם ניהול הביצועים.

מסתמן כי תחום ה-ERM (ניהול סיכונים ארגוני) יהפוך להיות באזוורד חשוב לא רק לבנקים/ חברות ביטוח וחברות שעוסקות בRISK בצורה מסודרת, אלא יתרחב גם לתחומים שונים בארגון (שיווק, HR וכד'). השאלה העיקרית תהיה: כיצד מנהלים תחום כ"כ רחב, שאמור להוות מרכיב בכל החלטה אסטרטגית שהארגון לוקח, אמור לעניין כל מנהל מחלקה עסקית בארגון, וצריך להיות משולב הן ברמה האסטרטגית והן ברמה הטאקטית (איך מבטיחים שנושא ניהול הסיכונים נאכף)?

שוק ה-MDM: ההבטחות, הסיכונים, התועלות

מאמר שכתבתי התפרסם לאחרונה ב DailyMaily:

כל מי שעוסק בתחום ניהול נתונים / MDM / איכות נתונים נתקל במונח מאוד "אמריקאי" שנקרא Data Governance: התהליך השלם של טיפול במחזור החיים של ניהול נתוני אב לאורך כל הארגון. נתוני האב מתייחסים לישות מסוימת (לקוח/מוצר/ספק/עובד/אחר), והמטרה היא לגרום לכל הארגון להסתכל להתייחס ולטפל בנתוני האב (שם, כתובת, סטטוס וכד') של אותה ישות בצורה מרכזית, אחידה ומנוהלת. לכל "נתון אב" שכזה (לדוגמה, כתובת למשלוח דואר) יש מישהו שאחראי על זמינות אחידות ועקביות אותו נתון לאורך כל הארגון.
בהרצאה מצוינת אותה העביר Aaron Zornes, מומחה מוערך וידוע בתחום, מייסד ומנהל ארגון ה-MDM Institue, עלו כמה מגמות חשובות לשנים הקרובות בתחום MDM ,Data Governance והקשר שביניהם:

• בשל המצב הכלכלי בשנה האחרונה 20% מפרויקטי ה-MDM הגדולים בעולם קפאו ונמצאים במצב on hold, אך עדיין מוציאים כסף על data governance כי אין ברירה. ההערכה היא שהתחום יגדל בשנים הקרובות, משום שעכשיו זה זמן טוב לטפל ב-MDM בשל צירוף של הכלכלה המתאוששת עם הרגולציה המתחזקת (במיוחד בתחום השירותים הפיננסים). ארגונים ינסו לשפר את מצב בשלות ה-DG שלהם, רובם יעסקו בנושא הלקוח כנושא עיקרי (תחת ההנחה שרווחת בהרבה ארגונים כי נתוני המוצרים שלהם תחת שליטה).
• כיום עדיין קיימת הרבה מאוד בנייה של פתרונות (לעומת אימוץ כלים) על ידי יועצים ובתי תוכנה שונים. אין סטנדרטים. כל אחד עושה את זה שונה. אין ספק שהשוק יבשיל אך זה ייקח זמן עד שהתחום יהפוך להיות Mainstream.
• הבנה כי DG (אחריות ניהולית על נתונים) הנה חלק בלתי נפרד מפרויקט MDM ולא משהו שנזכרים בו אחרי שמתחילים. (הדבר קצת מזכיר מה שקרה בישראל בתחום ה-balanced scorecard, כאשר ארגונים מיהרו ליישם טכנולוגיה ונזכרו בתהליך העסקי של הגדרה מסודרת של מטרות הארגון, יעדים וגזירת מדדים כמחשבה שלאחר מעשה). המסר העיקרי הוא שלא ניתן להפריד את נושא ה-Data Governance מנושא ה-MDM.•
• MDM טומן בחובו תהליך פוליטי בארגון, במהלכו יש להחליט מהם מקורות הנתונים האמינים עליהם הארגון צריך להישען. יחידות בעלות כוח בארגון בדר"כ לא ירצו לעבוד בשיתוף עם המחלקות האחרות, אין ממש תמריץ לעבוד ביחד. התוצאה היא שמחלקות מסוימות חושבות שהן ה"בעלים" של נתונים, וחלק מהמאמץ בפרויקט MDM הוא לעשות מעבר תפיסתי מגישת ה ownership על נתונים לגישת ה-sterwardship: אף אחד לא ה"בעלים" של המידע ולא משנה כמה כוח יש לו.
  

בהרצאתו, זיהה זורנס שני סוגים של פתרונות:

• פתרונות ניהול נתונים פסיביים (Passive Data Governance): מגיבים לדברים שקרו לא טוב באיכות נתונים, ובונים חוקים בשביל לטפל בזה. רוב השוק נמצא כאן והפתרונות הטכנולוגיים ברובם משתייכים לקטגוריה זו.
• פתרונות ניהול נתונים אקטיביים (Active Data Governance): גישה פרואקטיבית - מפעילים חוקים עסקיים שהוגדרו מראש לניהול של מידע עסקי.
• מבחינת הספקים, רובם, על פי הגדרתו של זורנס, הנם Passive-Aggressive (אומרים שהם ACTIVE כאשר למעשה הם PASSIVE).אנו אכן רואים שרוב הספקים הולכים לכיוון האקטיבי, אך הלקוחות עדיין לא ממש שם מבחינת הצרכים שהם מביעים. אין ספק שהתועלת העיקרית העסקית האמיתית טמונה בפתרונות אקטיביים עם מעורבות עסקית גבוהה בהגדרת החוקים העסקיים סביב הטיפול בנתונים.

זורנס גם ציטט תוצאות של מחקר של יבמ לפיו:

1. DG יהפוך לדרישה רגולטורית. קורה כבר באירופה עם תקן ISO 8000-9000 יש שם חלק שמדבר על תהליכי טיפול בנתוני לקוחות, תקן זה מתחיל לחלחל לארה"ב.
2. בדוחות מאזנים איכות נתונים יהפוך להיות ערך מדיד (הערכה אותה שמענו כבר כמה שנים ובינתיים כלום לא קרה).
3. חישוב סיכון הקשור לנתונים - משהו שהIT יצטרך לעשות ולדווח לארגון (לדוגמה, ניהול קשרים של לקוחות עם אנשים אחרים לאורך זמן רב, ניהול היררכיות וכד'.)

DG זה לא תהליך BATCHY אלא משהו שצריך לקרות בזמן אמיתי - מי ניגש לנתון? מה הוא עושה איתו? זה לא "הכל או כלום", יש נקודות כניסה שונות.כמעט בכל חברת ייעוץ בתחום MDM תמצאו שקף דומה שמדבר על מצב הבשלות של Data Governance בארגונים: האם קיימת "אנרכיה" (מושכים נתונים כשצריך, ברמת האפליקציה), האם "פדוליזם" (ה IT הנה הגוף שמניע את הנושא), "מונרכיה" (מצב יותר טוב - אנשי הביזנס מניעים את הנושא), "פדרליזם" – הגישה המנצחת, גישת ה SOA. מהניסיון שלנו בשיחות עם ארגונים, לרוב לא ממש קיימת אנרכיה אלא פדוליזם – יש איזו שהיא מדיניות בIT לסינכרון נתונים תפעוליים בשיטות שונות, אך אין שילוב של ראייה עסקית.

בהרצאה, זורנס עקץ את ספקי כלי ה-MDM באומרו כי רובם נבנו בראייה שניהול נתונים הנו מאמץ פרויקטלי שמתבצע בצורה Batchית (כלומר תהליך פסיבי), וכי המתודולוגיות וההתנהלות בתחום הנה פרויקטלית, במקום לגבש ראייה ממוקדת נכסים (נתונים = נכס) שיש לנהל לאורך זמן, לקבוע חוקים עסקיים לטיפול בנתונים בצורה פרואקטיבית ולא לאחר מעשה.ביקורת נוספת היא שאין התייחסות לקהילה הארגונית כאלמנט חשוב בניהול נתונים (לדוגמה, ויקי לבניית מילון ארגוני בארגון גלובלי) אלא תחת ההנחה שמישהו אחד מחליט בעצמו על הנתון.הוא העריך כי נותני השירותים הגדולים - הSIs הגדולים - יתמקדו באספקת מסגרת ל MDM בשנה הקרובה, וכי ספקי החבילות הטכנולוגיות יספקו פתרונות ACTIVE DG אמיתיים ב-2011-12.

בעיית כ"א:

על כל 1$ שארגון מוציא על תוכנה של MDM, הוא יוציא 3-4$ נוספים על מרכיב השירותים בפרויקט (לספק שירותים – SI). כיום קיים מחסור גדול באנשים בעלי ניסיון ממש של ניהול פרויקט MDM מוצלח (קשה למצוא אחד כזה, בלתי אפשרי למצוא שניים). יש הרבה אנשים שהוכשרו אך אין הרבה עם ניסיון ובטח שלא ניסיון בפרויקט מוצלח.

מהו הROI של MDM?

במצגת בנושא MDM ROI, הוצג מודל של אורקל לבחינת ROI של MDM, וגם הוצג Case Study של לקוח. ארגונים נוטים לחשוב ש-MDM ו-ROI לא הולכים ביחד. אולם דווקא בגלל ש-MDM זו טכנולוגיה תומכת, יותר תשתיתית מאשר אפליקטיבית, חוסר היכולת "להראות" למנהלים העסקיים משהו מוחשי רק מדגישים את הצורך לבצע business case ולהציג הצדקות עסקיות.

במצגת, אורקל הציגה תוצאות של בחינת ROI שהיא עשתה בקרב לקוחותיה, שמתרכז בתחומי צמיחה, הגברת אפקטיביות, ושיפור הAgility של מחלקת ה-IT. הנה כמה דוגמאות לתועלות שנמצאו:

• הורדת זמן הזמנות ב-2% כתוצאה מיישום MDM לנתוני מוצרים (PIM)
• שיפור אחוז ההיענות לקמפיינים ב-15%
• הורדת עלות סיכון אשראי ב-2%
• הורדת עלויות שנתיות לטיפול בתאימות לרגולציה ב-75%
• באופן כללי, החזר השקעה תוך פחות מ-12 חודשים.בנוסף,
• הודגש כי MDM לניהול נתוני לקוחות משפר את הROI ממערכות CRM (לדוגמה, שיפור פרודוקטיביות במוקד השירות כתוצאה מיישום CRM בסביבות 13%, שיפור כתוצאה מיישום CRM + MDM: 18%).

בכנס הוצג Case study של חברת Zebra העולמית, שיישמה פיתרון MDM של אורקל (UCM מבית סיבל). בחברה זו לפני הכנסת MDM עבדו 140 (!) מערכות תפעוליות שונות שטיפלו בנתוני לקוחות. כ 90% מתקציב הIT הופנה למאמצי תחזוקה של מערכות legacy, כתוצאה מכך גוף הIT נתפס כגוף טכני בלבד ללא השפעה אמיתית על הביזנס.מצד אחד, במצגת הודגש ההבדל הגדול בין חברות גדולות בינלאומית לחברות ישראליות (בחברה זו בעבר נתוני לקוחות הוכנסו ב 140 מערכות תפעוליות שונות!) ומצד שני תוארו כמה אתגרים עיקריים וניתנו טיפים ליישום שבהחלט ניתן ללמוד מהם:

בהתאם להמלצה שלנו ושל אנליסטים נוספים בתחום, הארגון המליץ על גישה מדורגת. כל שלב צריך לקחת בין 3-6 חודשים וכל שלב בפני עצמו צריך להציג תועלת עסקית (הCase Study בחברת Zebra שהוצג בכנס אכן דיבר על שלב ראשון של הכנסת התשתית תוך חודשיים באמצעות 2 אנשים, אולם מבחינת התועלת העסקית לא נראה כי היא הושגה בשלב זה שהוגדר כ"הנחת התשתית" לפרויקט).

מאמץ עיקרי היה להעביר מנהלי אפליקציות/תחומים עסקיים מהלך רוח של data ownership (בעלות על נתונים) ל data stewardship (נותני שירות - מספקי נתונים לשאר הארגון).

מבנה ארגוני – מצד אחד פונקציה מרכזית גלובלית "Data Governance", מצד שני "Data Stewards" שמשויכים לאזור מסוים ולתחום אפליקטיבי/עסקי מסוים. ה Data Stewards חוטפים על הראש מהDG במקרה שמשהו לא עובד כמו שצריך.בין התועלות שהושגו כתוצאה מיישום MDM (שעדיין ממשיך) בחברה זו כלל גם הפחתה של 60% בעלויות הIT (אשר, כזכור, משקיעה מאמצים רבים – כ90% מכלל המאמצים – בתחזוקת המערכות השונות והאינטגרציה ביניהן).

פרשנות STKI

בתכנון פרויקט MDM צריך לקחת בחשבון מקדמי סיכון ולא להיות מופתעים יותר מדי כשמתעוררים משברים בפרויקט מאתגר זה (במקרה זה תמיכת הנהלה בכירה מאוד תעזור). הסיכונים הכרוכים בפרויקטי MDM: מציאת כ"א (כולל מנהלי פרויקט, יועצים וכד') מנוסה באמת שיכול לחלוק מידע ולדעת ממה להיזהר. השינוי הארגוני שכרוך באימוץ MDM הוא משמעותי, החל מנציג השירות אשר עבורו תהליך פתיחת לקוח/שינוי פרטים ישתנה, דרך מנהלי תחומים שיידרשו להתיישר לפי סטנדרטים של master data כלל ארגוניים, דרך שינויים שצריך להכניס באפליקציות הלגסי שיעבדו מול אותו HUB מרכזי (ולא מול ה-master data שנמצא בבסיס הנתונים של המערכת עצמה). מציאת יועצים ומומחים בתחום שידעו להזהיר מהמכשולים הצפויים או להימנע מהם מראש תהיה משימה כמעט בלתי אפשרית.בנוסף, יש מבנה ארגוני שלם תומך שיש לגבש: אותה ועדת Data Governance אליה ידווחו Data Stewards. סביר להניח שבארגונים ישראליים, בשל העובדה שאין ארגוני ענק בישראל, data stewards יהיו אנשים שיעשו זאת רק כחלק מעבודתם השוטפת. לא ברור האם תהיה ועדת Data Governance ותחת מי היא תשב. כרגע רוב יוזמות ה-MDM שעולות מגיעות ממחלקת הIT ואנו לא רואים עדיין מעורבות עסקית מספקת בתהליך זה. הנחתנו היא שבישראל הגוף העיקרי שיניע פרויקטים כאלה יהיה גוף ה-IT, זה לא אומר שהפרויקט בהכרח נדון לכישלון, אך במצב כזה צריך לעשות מאמצים לגייס כמה שיותר שותפים בכירים בהנהלת הארגון ובמחלקות העסקיות השונות. ואם גופי IT בישראל ירצו לערב יותר את הביזנס (מה שאין ספק שצריך לקרות כדי שפרויקטים אלה יתרוממו) הם חייבים להתחיל לדבר במונחי תועלות עסקיות, כדוגמת אלה שתוארו כאן. בשל חוסר ניסיון בישראל בתחום ה-MDM, כדאי לנסות וליצור קשר עם ארגונים (או באופן עצמאי או באמצעות המיישם/ספק החבילה) שיישמו חבילות MDM בחו"ל וללמוד מניסיונם.בכנס אורקל הוכרזו פתרונות אורקל חדשים בתחום ה-MDM לניהול נתוני ספקים, ניהול נתוני רכש לארגון גלובלי). נראה שמגמה זו של אספקת פתרונות שונים ייעודיים לישויות השונות (MDM לנתוני לקוחות הנו מוצר אחד, MDM לנתוני מוצרים – מוצר שונה) מאוד שכיח בקרב הספקים (לכל סוג של פתרון יש מודל נתונים שונה). אולם לאחרונה ארגונים בחו"ל מתחילים לגבש מחדש ארכיטקטורת MDM, בשל איי ה-MDM שמתחילים להיווצר בארגונים – MDM לנתוני לקוחות, MDM לנתוני מוצרים וכד'. נוצר צורך לקשר בין אותם איים, כך שלמרות שבהחלט מומלץ ליישם כלי MDM בגישה מדורגת, ולטפל בעולם נתונים אחד כהתחלה לפני שעוברים לעולם נתונים שני, אך עדיין צריך לחשוב על היישום הכולל ככזה היאפשר לקשר בעתיד בין האיים השונים.

To ERP or not to ERP?

בכמה שיחות עם ארגונים שעדיין לא נכנסו לERP ושוקלים את צעדיהם בתחום עלתה השאלה – האם כיוון הERP הוא כיוון שכדאי לקחת היום, לאור הניסיון הרב הנצבר, או שכדאי להשקיע בתחומים אחרים שיניבו ערך עסקי גבוה יותר?

במקביל, בשנה האחרונה שוחחתי עם שני ארגונים שכבר יישמו ומפעילים מערכות ERP, ושוקלים האם בדיעבד הכניסה של הארגון לתחום ה ERP הייתה כדאית (שאלה שמחלקת הIT קיבלה מההנהלה הבכירה)? מהן התועלות שהתקבלו?

אני מחלקת את פרויקטי ה ERP לשני סוגים (חלוקה הכרחית כדי לענות על שאלות אלה):

ERP 1: זהו הERP הקלאסי שכולל את התחום הפיננסי, הלוגיסטי ומשאבי אנוש. בתחום זה ארגונים מעוניינים להיות "סטנדרטים" ולעבוד בצורה דומה לזו שארגונים אחרים עובדים. עוד לא פגשתי ארגון שראה תועלת בפיתוח של מערכת הנהלת חשבונות ייעודית לצרכיו הספציפיים. להערכתי, כאן אין שאלה וברור שיישום ERP הנו הצעד הנכון – תחום ה ERP מספק את ה best practices / התהליכים הארוזים הג'נריים, שדומים וצריכים להיות דומים לאלו שמנוהלים בחברות אחרות. קטלוג סוג התועלת העסקית המתקבלת ממערכות ERP תחת קטגוריה זו, לדעתי, אינה צריכה להיות "חיסכון בעלויות פיתוח המערכות", או חיסכון בעלות הממשקים בין מערכות שונות, וגם לא בכיוון של התייעלות הארגון וחיסכון בעלויות, אלא לדעתי צריך להסתכל על מערכות ה ERP כמערכות תשתית לכל דבר – תשתית אפליקטיבית הכרחית. לאחר יש פה גם את האלמנט של "יישור קו" עם התעשייה. לדעתי, הערך העסקי עליו ארגונים דיברו בכניסה לפרויקטי ה ERP מגיע אח"כ, בשלבי ה ERP הבאים... אבל כדי להגיע אליהם צריך ליישם את אותה תשתית אפליקטיבית – ה ERP 1 – זהו הבסיס ממנו ניתן לצמוח הלאה.וכאן אני רוצה להדגיש את ההמלצה שכבר הפכה להיות שחוקה, אבל היא כ"כ נכונה, במיוחד לאור זאת שמדובר על תשתית אפליקטיבית שאמורה להיות די דומה מארגון לארגון – להיצמד עד כמה שניתן לחבילה. בישראל אנו נוטים לבצע שינויים רבים בחבילות מדף, ובתוכן גם חבילות ERP (עפ"י נתון באדיבות NessPro– המתבסס על מוצר בשם Intellicorp אותו היא מייצגת בישראל, ארגונים משתמשי SAP מפתחים כ-30% קוד מקוסטם לעומת סטנדרטי! זהו נתון מדהים כשלוקחים בחשבון שההמלצה היא לשקול פיתוח אם מדובר על שינוי של מעבר ל10-15% בחבילת המדף). מבדיקות שעשיתי לאחרונה על יחסי כוח אדם במחלקות ERP ראיתי קשר ברור בין רמת הקיסטום של הERP לגודל מחלקת הERP שתומכת בו לאורך זמן. אין ספק שארגונים שנצמדו לסטנדרט הרבה יותר יעילים ביחסי כ"א שלהם לעומת ארגונים שפיתחו דברים ייחודיים, וגם הרבה יותר גמישים "לשחק" עם נושא ה sourcing (להשתמש בחלקי משרות חיצוניות במקום להחזיק אדם פנימי במשרה מלאה לנושא מסוים פשוט כי הוא "מכיר את הייחודיות של הארגון שלנו").

ERP 2: השלב בו רוב הארגונים הגדולים בישראל נמצאים כיום, לאחר הכנסת ERP 1. כאן מדובר על הכנסת מודולים שכבר יותר מתקרבים לעיסוקו הייחודי של הארגון, והשמים הם הגבול מבחינת הערך העסקי האפשרי. בזכות אותה תשתית אפליקטיבית שיושמה בשלב ה ERP1, הארגון יכול להתרחב לתחומים שונים ולהכניס מודולים חדשים, בהנחה שהספק בדר"כ יקדים את צרכי הארגון (לדוגמה, כאשר נכנסת רגולציה חדשה בשוק וספק ה ERP כבר פיתח/רכש יכולות אלה, כך שהארגון יכול להתמודד עם דרישות אלה ע"י הכנסת אותו מודול, מה שהיה מצריך ממנו מאמץ גדול הרבה יותר בפיתוח היכולות בעצמו). כלומר, ההתקדמות הזו עם צרכי השוק והארגון זהו בעצם הערך האמיתי שמתקבל בסוף הדרך. ההתרחבות כאן היא גם לתחומים ורטיקליים/תחומי ליבה, וגם לתחומים הוריזונטליים (לדוגמה, הכנסת מודול ניהול סיכונים, תכנון תקציב, פורטל משולב, BI משולב וכד'). משלב זה, ה ERP 2, בהחלט ניתן ורצוי לצפות לתועלות עסקיות, שהתקבלו בזכות אותה תשתית אפליקטיבית – ה ERP 1.הבעיה מתחילה כשההנהלה מחליטה לבדוק בסופו של שלב ה ERP 1 (לאחר מאמץ לא מבוטל, בדר"כ, של כל הארגון), מה בעצם קיבלנו מהמאמץ האדיר הזה?

לסיכום, כדי להתחיל להתמודד עם השאלה – To ERP or not to ERP – הארגון צריך לענות על השאלה עד כמה הוא מעוניין לעבוד "סטנדרטי" כמו ששאר התעשייה עובדת? באילו תהליכים כן ובאילו לא?בכל מקרה, בחירה בכיוון ה ERP צריכה לגרור אחריה תהליך תיאום ציפיות עיקש בנוגע לסוג הערך שאמור להתקבל מפרויקט זה. תיאום ציפיות זה עשוי לעזור באותה שאלת הערך והתועלת העסקית, וגם לסייע במיזעור הלחץ מהגורמים העסקיים להתאים את החבילה לצרכיהם הייחודיים. יש להבהיר כי כניסה לעולם הERP משמעותה התיישרות לפי תהליכים עסקיים סטנדרטיים ולשאוף עד כמה שניתן (תחת האילוצים הרבים הקיימים, שבחלקם פוליטיים) לבצע שינויים הכרחיים בשלב השני של הפרויקט, בו המשתמש יותר יודע מה הוא צריך. הארגון גם צריך להבין שהכנסת ERP משמעותה הכנסת תשתית אפליקטיבית שמרגע הכנסתה תהווה מעין "ברירת מחדל" לתחומים אפליקטיביים שונים שהארגון ירצה להיכנס אליהם, והשאלה הראשונה שישאל – "למה שלא ניישם את המודול של ספק הERP שלנו – שהפך להיות ספק האפליקציות שלנו?" ותשובה שלילית לשאלה זו תצטרך להיות מנומקת. כלומר, הארגון בוחר שותף אפליקטיבי שילווה אותו בצרכיו האפליקטיביים העתידיים השונים.

From the diary of a digital immigrant

I wasn't "born into the facebook revolution, I'm in no way a "generation Y" or a digital native. When I first heard of Twitter I thought it was the most ridiculous concept. I couldn't understand why anyone in their right mind would want to participate in all this social stuff. I'm a pretty private person, so posting so much information about myself and exposing it for the world to see was the most un-natural thing for me.

Actually, it still is.

The only difference is that now I see the value in all of this. I think there are different types of benefit categories to be gained from social media:

Know "what's going on":
Being a research analyst, I have to be updated about my coverage topics (Enterprise applications, Business Intelligence, Knowledge Management, Social tools, MDM, BPM etc.) Staying on top of things means I have to go through about 20-30 websites a day. With 4-5 meetings a day there's very little spare time to read and research. The 70 people/sources I currently follow on Twitter actually provide me with the highlights of what's going on in topics that interest me in a nutshell, and that's pretty cool. This is REAL value for me. It's kind of the same value I would have gotten from RSS but it's all pretty new to me.

Know what people are saying about your brand:
This is something I am, personally, less familiar with. But I think for companies who want to check out their brand impact, the acceptance of new products just released to the market, social media and things like Twitter in particular, can give a real time snapshot that can begin to answer these types of questions. It doesn't replace traditional market research tools but should be looked at as a whole new set of tools that didn't exist so far because people didn't share so much real time data about what they're doing or thinking.

Damage control or crisis management:
Social media is the best platform, in my opinion, to provide instant, personal-like feedback to a crisis.
Of course, it also works the other way around: when your brand "messes-up" something, social media is the quickest way to make sure this mistake will spread around very quickly. Even if it's something very small, for example – 1.3 million (to date) people saw a video of a Comcast technician falling asleep on a customer's couch, while waiting on hold for Comcast call center.
At this stage, if a company's big enough that people will talk about it with their friends, it WILL have presence on social networks, like it or not. If a crisis occurs and is magnified in social media tools, the most effective way would be to reply by using the same social tools and social networks: respond by using the same media. For more – see an interesting post that discusses this "fighting fire with fire" strategy.

These are just a few examples of how social media provides the type of value that didn't exist before. I've been talking to several large companies in Israel lately on how social media applies to their organization. Most of them have no idea, some are actually thinking about it, but most are "brushing this trend away", saying they don't think there's real value.

I think companies should start to think and act quickly. And if most companies are not there yet, there's even a larger advantage to be gained for the early adopters.

Happy new year, Shana Tova!

טיפים ליישום פרויקט ERP

להלן כמה טיפים שנלמדו כתוצאה מפרויקטי ERP רבים שהתבצעו בישראל:

• לבחור היטב את אנשי היישום של הספק (לבדוק המלצות ויישומים קודמים), הדבר במיוחד נחוץ כאשר סוגרים פרויקט ב “Fixed". לדרוש אנשים ספציפיים עד כמה שניתן, גם אם זה אומר עלות גבוהה יותר. ארגונים רבים הדגישו כי איכות וניסיון אנשי היישום מהווים גורם מכריע בהצלחת היישום, ועמידה בלו"ז.
• מה שכבר נשמע כמו המלצה שחוקה לחלוטין מוכיח את עצמו - השלב הראשון של היישום צריך להיות כמה שיותר "סטנדרטי" (לנסות להיצמד לחבילה ולא לבצע שינויים רבים). לאחר שימוש של 2-3 שנים במערכת, המשתמשים הרבה יותר יודעים להגיד מה הם רוצים ואיך הם רוצים וצריכים לעבוד. ארגונים רבים נמצאים כעת בשלב זה.
  כמו כן, יישום סטנדרטי יסייע משמעותית בהמשך הדרך להוריד עלויות תחזוקה ותמיכה שוטפות. מסקר יחסי כוח אדם שביצענו בישראל עלה בצורה ברורה כי בארגונים בהם נצמדו יותר לסטנדרט, מחלקת ה ERP משמעותית קטנה יותר מארגונים בהם פותחו שינויים רבים והמערכת הותאמה משמעותית לצרכי הארגון. אין זה מפתיע, שכן הדבר משפיע ישירות על יכולת הארגון לעבוד מול ספקי תחזוקה חיצוניים. כשהיישום הנו סטנדרטי אפשר להיעזר בכ"א חיצוני בצורה יותר תכופה, מה שיכול לסייע בעבודה במודל של חלקי משרות במקום החזקת אדם במשרה מלאה לתפקיד ייעודי. בארגונים בהם היישום כ"כ ספציפי לאותו ארגון, אין ברירה אלא להחזיק אדם שמכיר את היישום והארגון ולא ניתן להחזיק אותו ב"רבע / חצי משרה". נציין כי בישראל רמת השינויים שארגונים מבצעים במערכות הERP (ובכלל) הנה גבוהה משמעותית מזו המקבילה בחו"ל. בהמשך אקדיש לכך פוסט מפורט.
• תמיכה לאחר עלייה לאוויר – משתמשים ציינו כי זהו נושא בעייתי שלרוב אינו מתוקצב / מוערך באופן מספק. תמיכה של חודש לאחר עלייה לאוויר לא מספיקה! זוהי התקופה שהארגון מתחיל לעכל "מה נחת עליו", משתמשים רק מתחילים להשתמש, ורק אחר כך מתחילות הבעיות והבדיקה בפועל של כל התהליכים שתוכננו. כל דבר שעושים בפעם הראשונה צריך ללוות את המשתמש. למודולים הקשים היו לקוחות שציינו כי היו צריכים ליווי של 4-6 חודשים.
• בפרויקטים כיום אני ממליצה בחום לבחון שימוש בכלי EPSS – Electronic performance support system או כלים אחרים המסייעים בתחום של הטמעה ולמידה מתמשכת. כלים אלה יכולים לסייע בהפחתת עלויות הדרכה ראשוניות ושוטפות, והנם כלים יעילים להדרכת והנחיית המשתמשים תוך כדי ביצוע הפעולות ברמה תפעולית.
• לתקצב ו/או לפרט בחוזה באופן פרטני את נושא ההדרכה –במיוחד בעייתי כשמדובר במספר גדול של משתמשים. אנחנו כל הזמן שומעים מלקוחות שתקציב ההדרכה היה נמוך מדי ולא נלקח בחשבון. היו מקרים בהם הספקים "ספגו" את רוב הפער אבל לעתים הארגונים עצמם. ישנם לקוחות שציינו כי הם לא חשבו לתקצב דברים כגון עזרים טכניים, הדפסת חומרי הדרכה... ארגונים אחרים הניחו ששיטת ה Train the Trainers תספק אותם ובפועל זה לא הספיק.
• ארגונים עמם שוחחתי המליצו כי אותם אנשים שמשמשים חלק מצוות היישום הפנימי בשלב הקמת הפרויקט ישמשו חלק מצוות ה- Center of Excellence של הפרויקט לאחר עלייתו לאוויר.
• נושאים שבעבר לא תוקצבו וכיום מקבלים יותר חשיבות: הסבת נתונים, טיוב נתונים ובדיקות. אלה פרויקטים חשובים בפני עצמם.
• המלצה חשובה אשר לפני כמה שנים לא ממש הייתה רלוונטית: להתחיל מראש, כבר בשלב הראשוני, עם BI ופורטל. לא לחכות ל"שלב ב". שילוב ה-BI כבר בשלב הראשוני מאפשר לקבל "תוצרים" מהיישום באופן מהיר, והפורטל צריך להיבחן ככלי המאפשר סביבת עבודה יותר נוחה למשתמשים. יש לבדוק אילו רכיבים פורטלים קיימים ניתן לקבל מראש מהספק (לדוגמה, בתחום הרכש וה HR לרוב ישנם "פורטלטים" מוכנים/סביבות עבודה מוכנות). מניסיון לקוחותינו, סביבת פורטל מעל ERP משפרת משמעותית את יכולת העבודה מול המערכת ומקצרת תהליכים "מסורבלים".

המלצות שונות נוספות ניתן למצוא:

1. כאן

2. כאן

3. כאן

מה ה ROI של BPM?

לא כל תהליך ממוכן מצריך BPM.

הפוסט הבא ב JargonSpy משווה בין BPM ל WIKI – השוואה שעל פניו נראית מאוד משונה – הטענה היא שכשם ש ערך WIKI בנוי מהרבה תתי-ערכים שחלקם מוגדרים וחלקם יוגדרו בהמשך, תהליך ב BPM מסתכל על אוסף של תהליכים אחרים, וחלקי תהליכים שכולם מגדירים תהליך עסקי כולל, כאשר את "אבני הבניין" (=הערכים) ניתן יהיה לבנות אחר כך בהדרגה. אבל יש הסתכלות כוללת על תהליך-על.

לקוח שאל אותי לאחרונה מתי נכון לעשות שימוש בחבילת BPM לעומת שימוש ביכולות הWF שבמערכת תפעולית, לעומת פיתוח סטנדרטי?

להלן כמה תנאים שצריכים להתקיים לדעתי, כדי שההשקעה בנושא ה BPM תשתלם לעומת פיתוח רגיל/שימוש בWF של מערכות תפעוליות:

• תהליך גמיש אל מול תהליך נוקשה
  ב BPM יש פוטנציאל בשיפור מתמיד של התהליך. אם התהליך הוא די סטטי, אשר לא אמור להשתנות עם הזמן, ואין פוטנציאל לתועלת משמעותית בשיפור התהליך, אזי הרבה פחות מעניין להשתמש בBPM לצורך "מיכון" של אותו תהליך ועדיף לקודד. כאשר מדובר בתהליך שיש לו חשיבות עסקית יחסית גבוהה לארגון, ששיפור שלו יכול לשנות משמעותית (וכמובן גם ליצור אפקט שיווקי מצוין ליוזמת ה BPM באותה ההזדמנות), זהו תהליך מתאים לBPM. לרוע המזל, תהליכים מסוג זה הם גם אלה שהנם בעלי סיכון גבוה יותר, בדר"כ לא ממש מוגדרים והגדרתם אינה עוברת בצורה הכי "חלקה", חוצי מחלקות/תחומים (ואז גם ישנה שאלה מי מנהל אותו), וקשור למספר מערכות שונות. שיפור תהליכים בעלי פוטנציאל ROI גבוה הנו בדר"כ גם יקר יותר למימוש באמצעות BPM וייארך זמן רב.
• תהליך בעל השפעה עסקית גדולה מול תהליך אדמיניסטרטיבי ששיפורו אינו משמעותי
  כלי BPM עוזרים לקשר בין צרכי המשתמש העסקי לתוצרים הטכנולוגיים, וזה לא רק ברמת הססמה. זה נשמע, כמובן, מצוין ודבר שכל ארגון היה רוצה, אבל לקשר הזה יש מחיר. לדוגמה, אם בעבר לכל שיינוי/תקלה שהייתה מתגלה בתהליך באפליקציה הפיתרון היה ברמה הטכנולוגית, מערכות BPM "מכריחות" לבצע שינוי עסקי לפני השינוי הטכנולוגי. זה יכול בהחלט להציק/להפריע לצד הטכנולוגי של העניין, אך משמר את אותו קשר חשוב בין ביזנס לטכנולוגיה. לדוגמה, BPMN – Business-process-modeling notation - השפה ה"גרפית" לתיאור תהליכים משמשת הן את המשתמש העסקי לצורך תכנון ומידול התהליך והן את המשתמש הטכנולוגי לתרגום אותו תכנון לתהליך ממוכן.
  כלי ה BPM, ובתוכם רכיב הניטור והאנליזה (ה-BAM) מאפשרים למנהל העסקי של התהליך לבחון באופן שוטף את התהליך, לאתר בעיות בזרימתו, לתכנן ולבצע סימולציות כדי לשפרו.

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

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

מי פה מנהל את ה-MDM?

אחריות על נתונים - Data Governance ("ממשל נתונים") - הנו תחום מלא בפוליטיקות, רגישויות, חשיבות עסקית גבוהה, אשר אמור להיות מובל / בבעלות מנהלים מהתחום העסקי בארגון, ולמרבה הצער, ברוב המקרים - משהו שכלל לא קיים בארגון.

בשנים האחרונות עולם ניהול הנתונים מקבל זרקור ותשומת לב מחודשת; הן הנושאים הטכנולוגיים הקשורים בניהול נתונים (וכאן נכנסים תחומים כדוגמת ניהול איכות נתונים, טיוב נתונים, ניהול רשומות אב - Master Data Managemetn, ניהול אינטגרציית נתונים וכד'), והן הנושאים העסקיים - Data Governance, Data Stewardship וכד'.

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

אז מי צריך לנהל מהלך של ניהול נתוני אב (Master Data Management)?
הנה רשימה של בעלי תפקידים שמעוניינים - או צריכים להיות מעוניינים - ב MDM. רשימה זו לקוחה מאתר מצוין, שמהווה מקור מידע עשיר ואיכותי לעוסקים בתחום ה-MDM. האתר שייך ל Aaron Zornes, שהנו אחד מהמומחים הראשונים שהחל לעסוק בתחום הMDM, הקים את ה MDM Institute ומעביר סדנאות בנושא.

מי אמור לנהל פרויקט MDM?
יש כמה תשובות לכך משום שישנם כמה היבטים לפרויקט MDM, כאשר על כל היבט אמון חלק אחר בארגון:

• היבט הניהול העסקי של הנתונים - לאחרונה מדובר רבות על מינוי Data Stewards (אין ספק שתרגום חופשי של המונח - "דיילי מידע" אינו מוצלח במיוחד). אנשים אלה בדר"כ יהיו נציגים ממחלקות עסקיות אשר אחראים על הגדרת "נתון אב" בתחום מסוים, עליהם לדאוג שנתון זה יהיה זמין איכותי ועקבי לכל אורך הארגוןן, הם אחראים על ניהולו השוטף וכד'). צד זה מנוהל ומובל על ידי מחלקות עסקיות בארגון.
• היבט ניהול טכנולוגי של הנתונים - הקמת התשתית, חיבורה למערכות השונות, שינוי תהליכי העדכון והעבודה הטכנולוגית פיתוחית. החלק הטכנולוגי יכול להיות מנוהל על ידי אנשים מתחום התשתיות ארכיטקטורה ואינטגרציה (אלה שעוסקים בתחומי תשתיות אפליקטיביות חוצות תחומים), או על ידי אנשים שהתפתחו מתחום הBI/DW. כיום בשוק הבינלאומי מתחיל להסתמן חוסר באנשי MDM. אופציה נוספת לגורם טכני מוביל הנה אנשי אפליקציה תפעולית העיקרית הקשורה לעניין שלשמו מוקם הMDM (לדוגמה, אנשי מערכת ניהול לקוחות אם מדובר בMDM לצורך ניהול נתוני לקוחות).
• יוזמת MDM בדר"כ מביאה להקמת "ועדת ניהול נתונים" חדשה, שכלל לא הייתה קיימת לפני כן. ועדה זו עוסקת בתחום הרחב של ניהול נתונים - Data Governance ולרוב תכיל בעיקר אנשי ביזנס אך גם אנשי IT. לכל "תחום עסקי" (לקוח/נתון פיננסי/מוצרים/ספקים). ועדה זו תהיה מעין מטריצה של אנשים שונים מתחום טכנולוגי ועסקי, ולעתים רבות תהיה ועדה וירטואלית (שכן אנשים החברים בוועדה יהיו בעלי תפקידים אחרים בארגון, אשר חוץ מביצוע תפקידם השוטף גם יקחו אחריות ובעלות על נתונים שונים).

ישנם כמה ארגונים (מחלקות IT) שמשוחחים עמנו כיום בהיבט היותר טכני על שיטות שונות לסינכרון נתונים תפעוליים (בין אם מדובר על DW תפעוליים שאחראים לעדכן מערכות תפעוליות, בין אם מדובר על ODS - Operational Data Store שממלאים אותה מטרה, ובין אם מדובר על בחינת תחום ה-MDM על היבטיו הטכנולוגיים בעיקר, ומעט על היבטיו העסקיים).

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