תפריט נגישות

מתודולוגיה ליישום מערכת ORACLE APPLICATION בארגון SMB

יישום מערכת ORACLE בחברת SMB נשען על מתודולוגיה בת ששה שלבים שקודם לה שלב ה-PRE SALE. במאמר זה נסקור את הנדרש בשלבים השונים.

כללי

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

יישום מערכת ORACLE בחברת SMB נשען על מתודולוגיה בת ששה שלבים שקודם לה שלב ה-PRE SALE. במאמר זה נסקור את הנדרש בשלבים השונים.

 שלב ה- PRE SALE

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

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

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

בצוע הפרויקט

 בצוע הפרויקט מתבצע בהתאם למתודולוגיה שבה ששה שלבים:

אתחול – PREARATION

אפיון – DEFINITION

עיבוד – ELABORATION

BUILD – בניה

VALIDATION – ולידציה

TRANSITION – מעבר

 

 

 

אתחול

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

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

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

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

MS PROJECT – המשמש לתכנון הפרויקט ברמת הערסלים (רמת על)

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

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

במסגרת תוכנית הטפול בנתונים -  DATA PLAN – מחליטים, בין השאר, לגבי הנושאים הבאים:

א. אלו ישויות נדרשות לטיוב נתונים.

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

ג. הסבות נתונים – איזה הסבות נדרשות, מה אוטומטי ומה יוקם ידנית.

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

 

סדר גודל לשלב האתחול – 4 שבועות 

 

שלב ה-DEFINITION

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

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

משך שלב ה-DEFINITION – 6 שבועות

שלב העיבוד

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

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

משך שלב העיבוד – 4 שבועות

שלב הבניה

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

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

משך שלב הבניה – 8 שבועות

שלב ולידציה

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

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

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

משך  שלב ולידציה – 4 שבועות

שלב המעבר

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

משך שלב המעבר – 5 שבועות

"עליה לאוויר"

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

תובנות מיישום מערכת ה-ORACLE בחברות SMB

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

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

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

כותב המאמר: יובל חי, מנהל תחום היישום בחברת UNITASK

ליצירת קשר: yuval.hai@unitask-inc.com

 

פרסום באתר