מאקסל למערכת עסקית: איך שומרים על כללי העבודה?

בוחרים את התהליך שצריך מערכת

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

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

קוראים את הקובץ עם מי שעובד בו

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

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

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

רשימת כללים חושפת את העבודה שמאחורי התאים

הופכים כללים לדוגמאות שאפשר לבדוק

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

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

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

מגדירים את משמעות הנתונים ובודקים את ההעברה

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

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

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

קובעים מי מחליט על המעבר ואיך חוזרים לפעילות

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

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

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

יוצאים מפגישת התכנון עם דף מעבר מוסכם

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

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