ארגונים רבים מגיעים למצב שהם לא מרוצים ממערכת המידע שלהם, או מהיקף הפתרון שמתקבל ממערכת המידע. מחד – מערכת המידע לא נותנת פתרון משביע רצון, הארגון מרגיש תקוע ולא מתקבל מענה מהספק.
מאידך – החלפת מערכת מידע, זה פרויקט מורכב, יקר ובד"כ טראומתי למדי, ואף אחד לא מבטיח שהמערכת החדשה תיתן מענה טוב יותר.
בכנס של 2019 ERP.ORG, שנערך בכפר המכביה, העברתי הרצאה בשיתוף עם עמיחי קידר מחברת אינטנטיה בשם – "לגלות את העומק שבחבילה" או אם תרצו –"דקה לפני שמחליפים – האם אנו בטוחים שהבעיה זו מערכת המידע?"
סיפרנו על פרויקט משותף שלנו, אצל לקוח שיש לו מערכת M3, התלבט אם להחליף את המערכת, ולבסוף החליט להישאר עם המערכת הקיימת, לשדרג לגרסא חדשה ולהעמיק את היישום.
איך אני יודע שמערכת המידע שלי לא נותנת פתרון מספק
יש סממנים רבים למערכת מידע שלא נותנת פתרון לארגון, הדרך הטובה היא פשוט לעשות סיבוב עם עיניים פקוחות בחברה, ואפילו לעצור ולשאול את העובדים, מה הם אומרים? מה חסר להם? מה הם היו רוצים שיהיה להם במערכת המידע? על מה מתבזבז להם זמן? מה גורם לטעויות?
- עבודה ידנית
- אקסלים/קבצים מחוץ למערכת – לניהול נושאים שהמערכת לא תומכת בהם
- העובדים לא משתמשים במערכת, חלקן שואלים את השאלות במקום לפתוח מערכת ולבדוק
- יש טעויות
- אין העברה טובה של המידע וקשר בין המחלקות השונות בארגון
אז איך יודעים האם צריך להחליף מערכת?
זו כבר שאלה יותר מורכבת.
ואת הבדיקה הזו מומלץ לבצע בשילוב יועץ חיצוני. ובכל זאת, מה כדאי לבדוק?
- פערים -בין הרצוי למצוי -מה הם הדברים שהייתי רוצה שינוהלו בתוך מערכת המידע ואינם מנוהלים שם כיום.
- היישום המצוי – יש להבין מה היקף המענה הניתן במסגרת המערכת הקיימת, וזאת על מנת שלא ייצור מצב בו, אנו בוחרים מערכת שמטפלת נהדר בפערים, אבל לא נותנת מענה לנושאים שעובדים היום בצורה טובה.
- האם הפערים טמונים ביכולות מערכת המידע? או אולי דווקא בתהליכים העסקיים של הארגון? או בנסיבות היסטוריות? אני נתקלת במקרים בהם מישהו זוכר שלא ניתן לתת פתרון לנושא מסוים במערכת כמו לדוגמא – הזמנת מסגרת, והארגון נמנע מלטפל בנושא במסגרת מערכת המידע – כי זוכרים שבעבר לא הצליחו למצוא מענה. אבל! מאז עברו כמה שנים, המערכת שודרגה והשתחררו גרסאות חדשות – ודווקא יש כבר יופי של מענה במסגרת המערכת, רק שאף אחד לא טרח לבדוק את הנושא בשנית.
או לעיתים יש איזה תהליך מאוד מיוחד – שאותו ביקש עובד שיצא לפנסיה והיום כבר לא משתמשים בו.
האם אני יכול לבצע את הבדיקה לבד? או באמצאות המנמ"ר שלי?
כיוון שמדובר בפרויקט שהוא מאוד משמעותי לארגון, עדיף לשלב בבדיקה יועץ חיצוני. למה?
- אורח לרגע רואה כל פגע -אנחנו בתוך הארגון כבר התרגלנו שדברים עובדים בצורה מסוימת, ויותר קשה לנו להיפתח ולחשוב על עבודה בשיטה שונה.
- יועץ מסתובב בארגונים רבים, הוא מכיר שיטות שונות לנהל את אותם תהליכים, ויכול לעזור לארגון לחשוב קצת אחרת.
- ליועץ שעוסק בפרויקטים יש ניסיון אחר ממנמ"ר, והשילוב בין יועץ שעובר פרויקטים רבים לבין מנמ"ר שמכיר טוב את הארגון הוא בדר"כ שילוב מנצח.
מה ההבדל בין פרויקט החלפת מערכת לפרויקט העמקת היישום?
הבדל גדול מאוד, בפרויקט של החלפת מערכת נדרשת השקעה ניכרת רק בכדי להגיע למצב הקיים, לאחר מכן נדרשת השקעה על מנת לשפר את המצב הקיים ולטפל בפערים. לעומת זו, אם בדקנו וגילינו שהמערכת יכולה ברמה הטכנית לתת מענה, ופשוט לא אפיינו נכון את הצורך, לא השקענו מספיק, השקענו בעבר ונעצרנו או כל קונסטלציה אחרת, אז רצוי מאוד לבדוק האם ניתן לקבל את המענה במסגרת המערכת הקיימת.
ייתכן ששדרוג גרסא והעמקת יישום יביאו אותנו למקום שרצינו בצורה מהירה יותר ועם השקעה מועטה יותר.
מה המשמעות של להעמיק את היישום? איך עושים את זה?
העמקת היישום הוא בד"כ פרויקט קל למדי, כיוון שמה שכבר עובד במערכת ממשיך לעבוד, ואין צורך לטפל בו, מטפלים רק בפערים, בתהליכים שאותם ברצוננו לשפר.
אם על ידי שדרוג גרסא, הוספת כלים נלווים או מודולים, טיפול והכנסה של אוטומציות ותהליכים לתוך מערכת המידע.
חשוב לזכור שישנם יישומים רבים שהתוצאה של לקוח לא מרוצה ממערכת היא שילוב בין :
- יישום פחות מוצלח או ישן
- חוסר השקעה בהדרכה והטמעה
- תהליכים ארגוניים – שכדאי אולי לחשוב האם ניתן לשנות אותם ולהתאים עצמנו ליכולות המערכת
או – כל התשובות נכונות.
אז לסיכום
שניה וחצי לפני שאתם נכנסים לפרויקט קשה ומפרך של החלפת מערכת (לפעמים אין ברירה וזה אכן נדרש), תעצרו, ותעשו בדיקה האם המערכת הקיימת באמת לא יכולה לתת פתרון.
