דוגמאות לאתגרים אותם ואיך פתרנו אותם באמצעות ERP
מנהלים נוטים לחשב את הרווחיות של המחלקה שלהם להם ההכנסות וההוצאות הישירות המוכרות להם, חישובים אלו לא בהכרח עולים בקנה אחד עם הדוחות הכספיים או תזרים המזומנים, גם בגלל שלכל מחלקה יש להעמיס הוצאות נוספות שלא מוכרות בהכרח למנהל המחלקה וגם בגלל שתקינה חשבונאית מאפשרת הכרה שונה בהכנסות ובהוצאות, למשל הכנסה שתנאי התשלום תלוי פרמטר מסוים אולי לא יוכרו בהכנסה לדוח הכספי אך מנהל המחלקה כן יחשיב אותה במלואה לתקופה האמורה, לכן בבנית מערכת בינה עסקית, החישובים מתבססים על שיקולים פיננסים ועסקיים ונוצרת אמת אחת שמאפשרת אמידה ותחזית מדויקת.
לקוח מוכר קיבל הרבה ריג'קטים מהלקוחות, הריג'קטים התקבלו בצורה שבה הלקוח היה מתקשר לאחר שלא קיבל את מה שדרש או שולח מיילים למנהל השירות, בכל פעם בדקו מה הלקוח ביקש וסיפקו לו את מבוקשו אך כמובן שזה אינו פיתרון שורש, הטמעתי שימוש במערכת קריאות השירות, כך שכל פניה של לקוח תועדה, מעבר לכך שירות הלקוחות התבקש לתחקר למה סופק ללקוח מוצר שונה מכפי שהזמין, למדנו שבמחצית מהמקרים הלקוח הזמין מוצר מסוים אבל בפועל מערכת הליקוט תרגמה זאת למקט שונה, במחצית השניה של המקרים גילינו שהמלקט לא ליקט באמצעות מסופון ולכן הטעות שלו לא עברה ביקורת. טיפלנו בגורמים אלו והמשכנו לעקוב, גילנו ירידה של 80% במקרים שלקוח לא קיבל את מבוקשו, כיום למנהל מערכת מדידה עם אפשרות לניתוח לפניות מהלקוחות, כך מנהל מחלקת שרות מאופן דיי מיידי מנטר ומשפר את השירות.
האחת החברות איש המכירות חישב את הרווחיות לפי מחיר המכירה ללקוח בהפחתת ההוצאות הישירות לייצור המוצר, לפי חישוב ידני שלו התקבלה החלטה באם לאשר את הפרויקט או לא, אך בסופו של תהליך נמצא שלמרות שאושרו לאורך כל הדרך רק פרויקטים ברווח של 40 אחוז ומעלה, בפועל, הרווחיות הישירה עמדה על 28%, לאחר בחינה מדוקדקת הוחלט להטמיע את מודול הפרויקטים, כל שעם הכנסת ההזמנה חושבה הרווחיות והעלויות לפי עץ המוצר ולפי העלויות העדכניות, כל החלפה של פריטים הועמסה על הפרויקט, כך גילנו את ה"חורים" ברווחיות.
החברה אשר יושבת באיירפורט סיטי, מידי רבעון אנליסט החברה היה בוחן איזה מהפריטים אינם נמכרים והופך אותם למלאי מת ומותיר למכור אותם בעלות ללא רווח, לא נעשתה כל בחינה מדוע כלל הוזמנו פריטים אלו, לפיכך מצאתי כי יש לבנות מנגנון להמלצה להזמנה, במנגנון זה המערכת המליצה כמה לרכוש מכל מוצר על פי מספר לא מבוטל של פרמטים, ההמלצה תורמה בלחיצה כפתור להזמנות רכש לספקים המועדפים של הפריט, מלבד החיסכון הלא מבוטל בתקנים, כעת, בכל פעם בפריט הפך למלאי מת ניתן היה לתחקר מהם המדדים שהביאו אותנו להזמין ממנו והאם ניתן לדייקם כדי שמקרה זה לא ישונה, המודל שופר וחוזר חלילה, עלות המלאי המת לרבעון פחתה ב40% כתוצאה מתהליך זה!
הפריוריטי מספק כלי נוח ויעיל לבניית תקציב, לאחר הקמת הסעיפים התקציביים שהותאמו לארגון טענו את הפריוריטי והעלנו את התקציב מול הניצול בפועל למערכת הBI, מנהלי החברה ראו מידיי בוקר סטטוס עדכני של ניצול התקציבי וידוע לכוון את העסק בהתאם, במידת הצורך להורות על עדכון התחזית
בחברה היושבת בלוד מנהלות החשבונות התלוננו חדשות לבקרים שרוב מוחלט של חשבוניות הספק שמתקבלו כלל לא מתאימות לקבלת הסחורה מבחינת כמות ואף הסכומים לא מתאימים, התבצע אירוע קייזן, משמע בחינת התהליך הקיים וניטור הגורמים לפי שיטת ניהול רזה, התברר שהסיבות היו רבות המספר, מספק שמנסה את מזלו ומפיק סכום גבוה מכפי שסוכם כי ידע שישולם לו הסכום הגבוה, למחסנאי שלא סגר קבלת סחורה חלקית, לספק ששלח כמויות נמוכות או גבוהות מהזמנת הרכש, בהתאם קבענו סט של סטנדרטים שאליהם כל המעורבים היו צריכים להתיישר, בתחילת התהליך מצאנו כי ב80 אחוז מהחשבוניות מנהלת החשבונות לא יכולה להתקדם, לאחר התהליך נמדד כי רק 12 אחוז מהחשבוניות לא הותאמו.
חברה אשר היתה קובעת מבצעים ספורדים מחוץ למערכת ומעבירה למנהלי המכירות מיילים לגבי המבצע, כתוצאה, הזמנות הלקוח היו לא רווחיות אך לא היה כל חיווי שהזמנה זו כוללת מוצרי מבצע. הפיתרון: ללא כל קיסטום (התאמה), ללא כל פיתוח, ללא כל עלות, הטמעתי את מודול המבצעים של הפריוריטי, כל המבצעים הוגדרו או כמבצע לתקופה מסוימת ללקוחות מסוימים או כמבצע קנה-קבל, מערכת הפריוריטי הבסיסית מאפשרת לנתח בהתאם את הרווחיות מהמבצעים בדוחות מובנים.
אנשי המכירות בחברה היו מדווחים על האפקטיביות שלהם בפגישה שבועית, אך מה לעשות, האמור לא התאים לירידה ברווחיות בדוחות הכספיים, לפיכך התחלנו למדוד במערכת בינה עסקית כל סגירת העסקאות בפועל מידיי יום, מעתה, הישיבות השבועיות התנהלו מול המערכת ומול התוצאות בפועל, מייד זוהו אנשי המכירות ה"כוכבים" אשר תוגמלו בהתאם ואלו שפחות אשר קיבלו סיוע בהגדלת המכירות.
בחברה אשר היתה מחויבת לספק ללקוח בזמן אחרת היתה משלמת קנסות נוצר צורך דחוף לעקוב בצורה מיטבית אחר אספקת הספקים להזמנות לקוח, הטעמנו MRP מלא אשר ייצר את הזמנות הרכש אוטומטית וקישר לפרויקט שאליו קושרה ההזמנה, לאחר מכן הצגנו במערכת הBI כל פרויקט (הזמנה) מול תאריך האספקה שהתחייבנו מול הלקוח ומול תאריכי האספקה שהספק התחייב אליהם, עיכובים וקנסות צפויים התגלו במיידית וטופלו.
לעיתים מספר העובדים שצריכים גישה לפריוריטי גבוה ממספר הרישיונות שברשותינו, עובדה זו גורמת לכך שחלק מהנתונים מופקים או נשמרים מחוץ למערכת, פורטל עבור העובדים, מצומצם, טריויאלי לשימוש זה הפיתרון, בפורטל ניתן לאפיין בדיוק את המסך או המסכים המסוימים שאותו בעל תפקיד צריך בממשק מהפריוריטי ואליו כך שעדיין המערכת המרכזית של הארגון נשארת הפריוריטי ולא נדרש לרכוש רישיונות מלאים לכל בעל תפקיד
