ביום יום אנחנו נדרשים לנהל מספר פרויקטים במקביל ובשילוב מחלקות שונות, לדוגמה, מנהלי פרוייקט, מרקטיניג, מכירות.
החלטתם שאתם רוצים להכניס מערכת מידע חדשה לארגון כדי להצליח לנהל, למדוד ולעקוב אחר הפרוייקט, שהרי הרבה פעמים איסוף הנתונים בפרויקט הוא ידני, ובלי היכולת למדוד ולהציג תובנות אנחנו כאילו הולכים באפלה.. ולכן, תיעוד הפעולות וניהול כל המידע והידע של המשתתפים בפרויקט, עוזר למנהלים לקבל החלטות חכמות יותר כאשר הנתונים מוצגים באופן ברור ומלא. עד כאן, החלטה נבונה! אבל איזה מערכת מומלצת?
בשוק קיימות מגוון תוכנות לניהול פרוייקטים (מאנדיי, אסנה, ms ועוד), הצלחת התוכנה תהיה בדרך שבה תכנסו אותה לארגון.
בארגון שלי משתמשים ב:
- 0%מאנדיי
- 0%מייקרוספט
- 0%מוצרי Atlassian
על זה יקום ויפול דבר. וזה עיקר המאמר. לאחרונה סיימתי הכנסה מוצלחת של מערכת טכנולוגיות לניהול משימות בארגון של עשרות עובדים. כיצד עשינו זאת?
הנה 7 אבני דרך להטמעה מוצלחת של כלים לניהול פרויקטים:
תחקיר - כדי שלא יהיו אי הבנות ופערים, לדוגמה, בין הגוף שבחרתם להכניס איתו מערכת חדשה, לבין עובדי הארגון. יש להבין את הצרכים של כל מי שאמור להשתמש במערכת. כגון צוותים, בעלי עניין בארגון, מנהלים, ספקים וכדומה. בצעו תחקיר מעמיק מול כל גורם שצריך להשתמש במערכת. שאלו מה תהליך העבודה של כל אחד מהם? איזה סוג מידע הם צריכים לדווח? שאלו את המנהלים, אילו נתונים חשובים להם לראות ״בסופו של דבר״? מהן ההרשאות גישה שירצו לתת לעובדים? בדקו עם ה-it בארגונכם, האם קיימים מגבלות כלשהם? כמו חיבור לאימייל הארגוני, אינטגרציות שתרצו לבצע בהמשך, תמיכה ותפעול של התשתית?
איפיון - לאחר שקיבלתם את כל המידע, והבנתם מי הגורמים השונים בארגון. כתבו מפת זרימת עבודה לפי הצוותים או הוורטיקלים השונים. חשוב לתת ב׳מפה׳ את כל האפשרויות השונות. לאחר שבניתם תרשים זרימה, יש לחזור למנהל הפרויקט בארגון / למנהל הישיר ולהציג בפניו את התרשים, בדקו שיש התייחסות לכל שלבי העבודה ובקשו לקבל פידבק מכל הגורמים שפעלתם מולם בשלב 1. לא תאמינו כמה שינויים ותיקוניים תקבלו לאחר שתשלחו לעיון והערות. איכות העבודה, תחסוך זמן יקר בעתיד.
תכנון - בשלב הזה פנו למומחה המוצר של תוכנה (מתוך הארגון או ספק מחוץ לארגון), שמסייע לכם לבנות מחדש את סדר העבודה שגיבשתם בשלב 2. המטרה בהכנסת בתוכנה היא לייעל תהליכים ולהפחית בכמה שניתן זמן עבודה מחזורית (הכוונה משימות שחוזרות על עצמן). בשלב הזה צריך לקחת זמן כדי לראות מה הדרך הטכנולוגית המהירה והחכמה ביותר שבה נמליץ דרך עבודה שונה וחדשה בכלי הטכנולוגי. בשלב הזה חשוב להדגיש כי יכולים להיווצר פערים בין הרצוי משלב 2 לבין המצוי במערכת הטכנולוגית, ולכן יש לראות מהן היתרונות והחסרונות שבהכנסת השינוי. מומחה המוצר, מציג את תהליך העבודה עדכני וכותב מסמך איפיון טכני שישמש בהמשך את המעצבים והמתכנתים/ מיישמים שבונים את המערכת בפועל. לאחר שהמסמך הטכני כתוב, הוא למעשה ״האורים והתומים״ של הפרוייקט, ובשלב הזה מקבלים החלטות כיצד ממשיכים עם הפרויקט.
דמו - שלב הפיילוט. כל מה שנאסף, גובש והוחלט סופית, מראה כיצד לבנות את הפרוייקט. ההמלצה המקובלת היא לבחור מחלקה/ צוות על כל מרכיביו ולבצע דמו של תהליך העבודה החדש. מטרת הדמו נועדה כדי להמחיש את תהליך העבודה אבל לא לשינויים נוספים. לאחר הצגת תהליך העבודה לצוות הנבחר, וקבלת פידבקים שונים נקבע תאריך להתחלת ההטעמה בצוות הנבחר.
הדרכות - יש לחלק את ההדרכות לפי בעלי סמכות. לדוגמה בין מנהלים לעובדים. מכיוון שלכל אחד יש את הצרכים שלו, כמובן שגם מסמכי ההדרכה הכתובים נחלק על לפי מחלקות ותחומי אחריות.
בדיקות מערכת QA- בשלב הזה נבצע הרצה של המערכת על כל מרכיבה ונראה איפה יש תקלות באוטמציות שביצענו, מה הפדיבקים שקיבלו מהמשתמשים החדשים.
פגישות משוב/ בקרה - מומלץ לתת זמן הרצה רטובה על המערכת, בה הארגון משתמש באופן קבוע במערכת. בתאריך מסוים (דדליין) נבקש לקבל פידבק מהמשתמשים.
למעשה, בתקופה הקרובה אתם נמצאים בתהליך עבודה מעגלי שחוזר בין הדרכת עובדים -> בדיקות/ פגישות בקרה -> הדרכות ועדכונים לעובדים.
לסיום, אני ממליץ כשניגשים לפרוייקט מבוסס נתונים, התחילו בעבודה מסדורת. שכוללת גאנט, ניהול משימות, דד-ליין, תיאום ציפיות ואיפיון. הסטינ׳ג והגבולות שתקבעו לצורת העבודה כמנהלי הפרוייקט, יבטיח את הצלחתו.