מחשוב ענן - כמו בטיסה - מצריך הבנה בעננים השונים וזהירות

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

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

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

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

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

המצגת תוצג בבלוג בימים הקרובים. זה משכתבו על זה ב- Daily Maily:

http://pc.co.il/dailymaily/?date=30-06-2013

פורטל ארגוני בעזרת קוד פתוח (ג'ומלה)

פורסם בכנס בנושא ביום עיון של ERP.org. קישור כאן.

שיווק אגף מערכות מידע וטכנולוגיות עסקיות

המצגת הוצגה בכנס ERP.ORG ב- 12 במרץ 2013. קישור כאן.

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

הגדרות כדי שנדבר בשפה אחת, אתחיל בהגדרות: מכירה – העברת בעלות או חזקה בנכס או ידע מצד המוכר אל צד הקונה בתמורה ותנאים מוסכמים. שיווק – לימוד שוק המטרה ויצירת דרישה למכירות (ביקוש). קידום מכירות (קד"מ) – כלים ליצירת דרישה למכירות. מכירה פשוטה נתחיל בתיאור תהליך המכירה – מצד הלקוח (תהליך הרכישה של הלקוח). התהליך מתחיל בצורך או רצון של הלקוח לרכוש מוצר מסוים או מוצר בתחום. לדוגמה – רכישת סמארטפון. הלקוח לפעמים צריך אותו לצורך עבודתו ולפעמים רוצה כיוון ש"לכולם יש". מבחינת המוכר אין היום הבדל אם המניע לרכישה הוא הרצון או הצורך. הלקוח מברר פרטים – עם חברים, באינטרנט וכו'. בשלב מסוים מקבל את ההחלטה, מבצע את הרכישה, ולאחר הרכישה וההפעלה משתף חברים ומשפחה בשביעות הרצון שלו. המפתח – אדם אחד הוא זה שעובר את כל התהליך, הוא המחליט והוא המבצע. אם המוכר משכנע אותו, אותו מוכר יבצע את המכירה. מכירה מורכבת במכירה מורכבת מעורבים אנשים רבים בתהליך. תהליך רכישת הידע יכול לכלול מספר אנשים. בחברה, לדוגמה, לפני החלטה על החלפת מערכת התקשורת עשויים להיות מעורבים, מלבד מערכות המידע, גם מחלקת התפעול ואולי יועץ חיצוני. המחליט עשוי להיות קבוצה של אנשים. יתכן שלאחר ההחלטה, אם העלות עוברת סכום מסוים, יהיה צורך באישור ההחלטה. בנוסף, כיון שההחלטה משפיעה על אנשים רבים בארגון, ימצאו תמיד התומכים והמתנגדים. כדי להבין היטב את התמונה בטרם תתקבל החלטה, כדאי למפות את התומכים, את המתנגדים ואת היועצים ואף בהפרדה גדולה יותר – מי מגיע מהמקום המקצועי, מי מהכלכלי (כסף), מי מהצד התהליכי ומי מהצד הארגוני (השפעה על הארגון ועל האנשים – המעורבים ולא מעורבים). שאלה נוספת שאנחנו צריכים לשאול את עצמינו היא – מי הלקוח? האם במקרה של הזמנת פרויקט ממערכות מידע או דו"ח, הלקוח הוא המזמין עצמו? המנהל שלו? הלקוח הסופי של הארגון? נראה שהלקוח יכול להיות כל אחד מאלו או כמה מהם במקביל: המנכ"ל סמנכ"ל המכירות סמנכ"ל השיווק סמנכ"ל הכספים סמנכ"ל התפעול היועץ המשפטי איש המכירות איש השירות המחסנאי הנהג המפיץ המוכרן בשרשרת האספקה אני טוען – הלקוח הוא הלקוח הסופי של הארגון. כל השאר הם שותפים בהבאת פתרונות ומיקסום התוצאות של החברה בעבודה מולו. הדבר נכון בכל ארגון שיש לו מטרות, ולא רק בארגונים למטרות רווח. מפתח להצלחת ארגון מערכות המידע – מיפוי נכון של הארגון והבנת מטרות הארגון, במקביל להבנת המשימות של כל אחד בארגון, כדי לעזור להם להצליח. שיטת SPIN השיטה הוצגה ע"י ניל רקהם בספר שנכתב בשנת 1988. הספר נכתב בעקבות ניתוח 35,000 שיחות מכירה במכירות מורכבות והאיר כמה נקודות: מכירות מוצלחות ביותר נעשות כשהקונה מדבר הרבה יותר מהמוכר איש מכירות טוב יוצר קשר אישי טוב עם הלקוח ושואל שאלות. ברוב הזמן לא מרצה ומסביר. השיטה מדבר על 4 סוגי שאלות: S Situation המצב הנוכחי P Problem הבעיות הקיימות, הכאבים I Implication דיון במשמעות הבעיות והמצב על הלקוח, פיתוח הצורך N Need – Payoff הבאת הלקוח להציג את רצונו, צרכיו ואת משמעותם, התועלת שלו ניל רקהם זיהה שאנשי מכירות המתרכזים במצב הקיים מאבדים מכירות ואינם אפקטיביים. אנשי מכירות שבודקים את הבעיות הקיימות מביאים תוצאות טובות יותר. דיון עם הלקוח על משמעות הבעיות והמצב על הלקוח ופיתוח הצורך, ובעיקר בעיות נסתרות בעלות משמעות רבה, מעלה את רמת התוצאות ושביעות הרצון של הלקוח בתהליך ואחריו. התוצאות הטובות ביותר מתקבלות כאשר הלקוח הוא המציג את רצונו, את צרכיו ומשמעותם, ואת התועלת שלו מהפתרון אותו מציע איש המכירות. האם אנחנו אנשי מכירות? אני מאמין שכולנו אנשי מכירות במידה מסוימת. אגף מערכות המידע מוכר פתרונות ובמיוחד היום, כאשר ניתן לקנות פתרונות גם בחוץ (ענן וכו'), אנחנו צריכים למכור ולמכור היטב. כיוון שמדובר במכירה מורכבת ומתמשכת, אנחנו צריכים, בעבודה עם כל גורם בחברה, להביא כמה שיותר מהר כל דיון לכך שהמשתמשים שלנו ידברו על רצונם, צרכיהם, משמעותם, התועלת בשבילם ולא פחות חשוב – איך זה מועיל לארגון וללקוחות הסופיים שלו. כך נשיג תוצאות טובות יותר ושביעות רצון גבוהה יותר (שתגרום להעדפתנו כנותני הפתרונות על פני פתרונות חיצוניים). על המיתוג תפקיד המיתוג הוא ליצור ערך בעיני הלקוחות והשותפים. לדוגמה – נעל ספורט של יצרן ידוע (נייק, אדידס וכו') עולה מאות רבות עד אלפי שקלים. נעל לא ממתוגת עשויה לעלות כמאה עד מאתיים שקלים. המיתוג יוצר ערך נתפס גבוה בעיני הלקוחות. על כן תפקידו לטפל בתפיסתנו בעיני לקוחותינו. יצירת מיתוג וערך למערכות מידע חשובה גם לטובת הארגון. מספיק להזכיר את עבודת קופות החולים והבנקים ביצירת יישומים סלולרים וגישה מהאינטרנט לעבודה מולם, דבר המשפר את תחרותיות הארגון ומעלה את שביעות הרצון של הלקוח הסופי. הדבר נעשה על ידי מחלקות מערכות המידע בשיתוף עם הגורמים המתאימים בארגון וממתג גם את הארגון אבל גם את מערכות המידע בתוכו. מיתוג מתאים יקבע מתי פונים לאגף מערכות המידע בחברה ומתי עוקפים אותו. אנחנו צריכים לדעת מתי מנהל בארגון רואה אותנו כשותפים לדרך, כמקדמים, כיוזמים או אולי כחסמים. ובסופו של דבר כל מנהלת ועובד מנסים להבין אם מערכות המידע מקדמים אותם או אותו או עוצרים. קידום מכירות גם פרויקטים שנהגו על ידי מנהל או מנהלת בארגון או פרויקטים לטובת שדרוג מערכות המידע, יתקבלו טוב יותר על ידי האנשים בארגון ויעוררו פחות התנגדויות לשינוי אם נקדם אותם בזמן ובצורה חכמה. לדוגמה , בחברה מסוימת ניסיתי להכניס אתר מידע פנימי לטובת הדרכות ושימור ידע. הדבר נעשה מתוך הבנה שבחברה אין הסכמה על תהליכים מובנים לגמרי, תחלופה גבוהה של אנשים מצריכה משאבי הדרכה רבים שלא קיימים, וצריך ליצור דרך לשימור ידע. אתר פנימי ייתן ערך מוסף גם בהעברת מידע לאנשים בחברה על הנעשה באגפים אחרים. כצפוי היתה התנגדות של חלק מהמנהלים לתהליך, חלק היו קטני אמונה ורוב המשתמשים לא ידעו בכלל שקיים דבר כזה. הפתרון היה הכרזה על תחרות נושאת פרסים לקביעת שם לפורטל הפנימי של החברה. היה בזה רצון לשימוש בתחרותיות האנשים כגורם מדרבן, ברגע שהוכרזה התחרות, החלו להגיע הצעות. בנוסף נקבע שהשם שייקבע יקבע על ידי הצבעה של כל העובדים בחברה. הפרס שהוכרז היה של 500 ₪ למחלקה הזוכה, שינוצל לפי שיקול המציע הזוכה. התוצאות: כ- 2/3 מעובדי החברה הצביעו הגיעו כ- 20 הצעות שונות חלק מהמציעים ביצעו קידום מכירות בעצמם ועודדו אחרים להצביע עבור שמות שהציעו. כך הם קידמו את האתר ואת הרעיון שמאחוריו גם כשאנשי מערכות המידע לא היו באזור. נבחר השם שזה במירב הקולות. גם ההכרזה על הזוכה ועל השם היו בעצם קידום מכירות. נעשה שימוש באתר להדרכת אנשים חדשים ולתיאום תהליכי העבודה בחברה. דוגמה – יצירת שותפות עם ארגון המכירות כדי לשתף פעולה עם כל אחד מהאגפים בחברה או בארגון, אנחנו צריכים לשאול את עצמינו מספר שאלות: מה שרשרת הערך? מה המוטיבציות של כל אחד בשרשרת? מה אפשר לתת ללקוח הסופי כדי שכל אחד בשרשרת יהיה מרוצה? מי מוביל בעבודה המשותפת? מי אחראי על העבודה המשותפת? אדגים זאת בעזרת דוגמה של יצירת שותפות עם ארגון המכירות במהלך העברת כל מערכות המידע מאוסף של מערכות ותיקות למערכות ERP חדשות שנעשה ביום אחד, בלי לגרום לעצירת הארגון או המכירות ובלי לפגוע משמעותית בשביעות רצון הלקוחות הסופיים. המפתח היה לזהות את שרשרת הערך מהלקוח הסופי אחורה, להבין את הצרכים והרצונות של כל אחד ולמצוא ביחד עם ארגון המכירות דרך ופתרונות שיענו על אלו בצורה מיטבית בהתאם ליכולות הקיימות. התחלנו בהסתכלות על הלקוח הסופי וצרכיו: רוצה מידע על המוצר רוצה מאיש המכירות מידע שלא ניתן לקבל בדרך אחרת (כמו מחיר מלא, מועדי אספקה וכו') רוצה תהליך רכישה מהיר רוצה תהליך רכישה גמיש (אמצעי תשלום, מועדי תשלום וכו') רוצה לקבל את המוצר מהר חשובה לו שביעות הרצון בעת קבלת המוצר ואח"כ צרכי איש המכירות: עמידה ביעדי המכירות עמלה אישית מכירות מהירות לקוחות מרוצים צרכי מנהל המכירות: עמידה ביעדי המכירות עמלה אישית מכירות מהירות לקוחות מרוצים כלי לעבודה – בדיקת תוצאות מול יעדים, תשלום עמלות, תמונת המכירות כך השגנו שיתוף פעולה לתוצאות במטרו מוטור: הבאת המערכת להבנה איך לעמוד במעבר המהיר ביותר למערכת החדשה כשזה יעשה ( Need-Payoff ) הבנת אנשי המכירות ומנהל המכירות הארצי למה שיביא אותם במהירות להשגת היעדים והעמלות ומה יכול להפריע להם הסכמה על תקופת עבודה במקביל על המערכות הישנות והחדשות כדי שמערכת המכירות לא תעצור במעבר זיהוי התומכים / המאמנים / מובילי השינוי בכל סניף ועבודה איתם השת"פ הוביל לעבודה במקביל של כל אנשי המכירות על שתי המערכות (הישנה והחדשה) במשך 6 חדשים. במעבר למערכת החדשה המכירות לא נעצרו לרגע, אנשי המכירות יכלו לעמוד ביעדים שלהם ונעשתה עבודה רבה ורצינית איתם כדי שיקבלו את העמלות המגיעות להם. סיכום אני מאמין שאלו המפתחות להצלחת אגף מערכות המידע והטכנולוגיות העסקיות: הדגשת השותפות מול הלקוח הסופי זיהוי תועלות השותפים בארגון והפיכתם למצליחים בעזרתנו תקשורת שקופה ומקדמת בתוך אגף מערכות המידע והטכנולוגיות העסקיות תקשורת שקופה ומשתפת מול שאר הארגון עשית ולא פרסמת – לא עשית!

מעתה אמור - CIO = סמנכ"ל טכנולוגיות עסקיות

סמנכ"ל טכנולוגיות עסקיות – בעיה או הזדמנות?

מאמר זה פורסם בגליון Information Week מספר 1386, עמ' 90-91. http://informationworld.co.il/infw1386/#

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

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

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

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

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

השאלה – האם את/ה היועץ/ת העסקית הטוב/ה ביותר לטכנולוגיות, היועץ/ת הטכנולוגי/ת הטוב/ה ביותר לעסקים או סתם טכנולוג/ית?

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

האם הגיע הזמן להגדיר מחדש את המקצוע?

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

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

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

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

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

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

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

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

יצירת שיתופי פעולה

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

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

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

 בהצלחה,

אלדד

בחירת מערכת BI

מה זה BusinessIntelligence (BI)?
מאמר זה פורסם בחוברת השנתית של ארגון המנמ"רים Business Alignment מיסודן של IDC ישראל ו- ERP.ORG.IL.

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

ברוב מערכות ה- BI ניתן להציג נתונים בצורה גרפית (שעונים, גרפים, תרשימי עוגות וכו').

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

ההבדל בין BI לביןדוחות תפעוליים

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

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

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

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

סוגי המשתמשים

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

·משתמשים ברמה הפשוטה יכולים לדרוש בעיקר תצוגה גרפית מסכמת של מדדים להצלחה (Key Performance Indicators – KPI)

·        משתמשים אנליטיים ידרשו טבלאות ונתונים על פי הגדרה מראש

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

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

תשתיות החברה

התשתיות האנושיות:
 

אלו התשתיות החשובות ביותר לפרויקט BI

המשתמשים ושיתוף הפעולה שלהם

·        יכולת הבדיקות של המשתמשים

·        יכולת ההגדרה של המשתמשים, כולל הבנה של שלבים בהתקדמות כדי לסיים את הפרויקט בזמן סביר ולהתקדם אח"כ בשלבים

·        משאבי מחלקת המחשב לניהול הפרויקט

·        משאבי מחלקת המחשב (בהווה ובעתיד) בנושא ידע ב- BI, בניית ידע פנימי במערכת מסוימת ופיתוחה

·        משאבי מחלקת המחשב החיצוניים המוקצים לפרויקט הראשוני ולהמשך פיתוח ותחזוקה אח"כ.

תשתיות המחשוב:

·        האם התשתיות הקיימות מספיקות לתוספת מערכת כזו?

·        ברוב המערכות המובילות יידרש שרת ייעודי לנושא. האם יש תקציב? האם מספיק לשרתים היעודים (ברמת אפליאנס – Appliance)?

·        ניהול השרת הנוסף –כיצד?

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

דרישות המשתמשים

·        האם מדובר על צורך בנתונים בזמן אמת או שנתוני הלילה שעבר מספקים?

·        האם בתוך כל הדוחות הנדרשים אפשר להפריד בין נתונים שנדרשים לזמן אמת או כמעט זמן אמת לבין אלו שיכולים לתת תמונה באחור של לילה או כמה שעות?

·        כמה משתמשים צריכים תצוגה מרכזת גרפית בלבד/בעיקר?

·        כמה משתמשים צריכים תצוגה אנליטית מוכנה מראש?

·        כמה משתמשים צריכים כלים לביצוע ניתוחים אד-הוק (שלא תוכננו מראש) ומה רמת הידע שלהם בנושא זה?

·        למתי צריך איזה חלק של הפרויקט?

·        מה סדרי העדיפויות בביצוע בין מחלקות החברה? בין הנתונים הנדרשים בכל מחלקה ובין הדחופים במחלקות השונות?

נתונים

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

הפרמטרים הבאים יגרמו לעבודה על הנתונים למשך זמן רב יותר:

·        ככל שהנתונים נפרשים על פני זמן ארוך יותר.

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

·        ככל שיש להוציא נתונים ממערכות רבות יותר.

·        ככל שיש לבצע עיבוד מקדים רב יותר על הנתונים לפני הצגתם בצורה המבוקשת על ידי המשתמשים.

ההיצע

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

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

חלק מהחלופות מתאימות לארגונים גדולים (Enterprise) ושם נמצאים כל או מרבית הלקוחות שלהם. חלק מהחלופות נמצאות רק אצל ארגונים קטנים ובינוניים וכנראה לא יתאימו לארגון גדול.

ניתן להיעזר בחברות יעוץ ידועות כגון IDC, Gartner כדי לבצע סינון ראשוני.

המשתמשים ואסטרטגית היישום

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

שיתוף בבחירה

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

אסטרטגית היישום

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

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

תיאום ציפיות

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

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

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

פרמטרים ראשוניים לבחירה

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

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

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

·        התאמת התוכנה לגודל החברה הקיים והצפוי. קיימות תוכנות שעובדות בעיקר בסביבת ארגונים גדולים (Enterprise),אחרות מתאימות יותר לסביבת SMB(Small & Medium Business).מה מתאים לארגון שלי?

דגשים ברמת משתמשים סופיים

·        ממשק משתמש – כמה נוח וקל לצרכי המשתמשים המוגדרים, ידידותיות

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

·        יכולת משתמשים סופיים לבצע ניתוחים לא מוכנים מראש (האם יש צורך, כמה אינטואיטיבי?)

·        ·דגשים טכניים

·        תשתיות התוכנה ותשתיות התוכנה של החברה והפתרון המוצעים (האם מתאימות לסטנדרטים של החברה)?

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

·        תלות במיישמים לשינויים בפרויקט ובעתיד

·        קלות ביצוע שינויים (ככל שקל יותר לשנות, יהיה זול יותר ומהיר יותר לקבל תוצאות מבוקשות)

·        תשתיות פיזיות נדרשות–צורך בשרת ייעודי? ניהול השרת הייעודי במקרה שצריך, השתלבות השרת הייעודי במערך השרתים בחברה

·        האם התוכנה יכולה לתמוך בכמות המשתמשים הדרושה?

·        היכרות מוקדמת של החברה עם התוכנה או של אנשים בחברה עם התוכנה (ברמה הטכנית, ברמת משתמשים)

·        ·מידת הקריבה לפיתוח בחברת פתרון ה- BI,רמת התמיכה

·        ·ניסיון המיישם בפרויקטים דומים בגודל, בענף

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

חישובי העלויות

בחישובי העלויות לפרויקט כדאי לקחת בחשבון:

·עלויות תוספת תשתיות

·        חומרת שרתים

·        מערכות הפעלה נוספות, תוכנות גיבוי וכו'

·        אחסון

·        תשתית וירטואלית (האם יש צורך להרחיב או לשדרג והאם ההרחבה כרוכה בתשלום)

·        ניהול התשתיות הנוספות

·עלות רכישת תוכן מוכן

·עבודת יישום חיצונית

·        הדרכות

·        יישום

·עבודת יישום פנימית

·        טיוב נתונים

·        אפיון המערכת

·        ניהול הפרויקט

·        יישום על פי החלטה

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

כיוון לעתיד

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

הבחירה

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

מומלץ מאוד לבצע Proof Of Concept(POC) בתנאים דומים ככל האפשר לתנאי החברה.

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

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

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

·        למתחרה השני שהביא מיישמת מצטיינת לקח יום שלם ליצור דו"ח ראשוני שלהערכתנו היה צורך בעוד כיומיים או שלושה לעדן אותו ולהגיע לתוצאות נכונות במלואן.

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

הפרויקט

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

חשוב לא פחות כמו בכל פרויקט – לתחם את הפרויקט, להכריז על סיום שלב ראשון ורק אח"כ להמשיך ולשפר את המערכת.

בהצלחה!

פרטי קשר:

אלדד גפן

eldad.gefen@google.com

054.80.88.770

תודות לגיל כץ ושלמהמרקוזה על הערותיהם.