עשה לך מפרט דרישות - תמיד
מפרט דרישות הוא מסמך חיוני בכל פרוייקט תוכנה ולמעשה בכל פרוייקט. למרות זאת קיימת נטייה בפרויקטי PLMבמקרים מסוימים לוותר על מסמך חשוב זה. בימים אלה מתנהל פרוייקט שבו נבחר ספק, ללא בחינת אלטרנטיבות באמצעות כלי בחינה אוביקטיביים. האינטואיציה של הצוות המחליט אמרה שהמוצר מתאים להם ועל כן ניתן להתחיל ביישום, ללא בחינה נוספת. ייתכן מאוד שהם צדקו וגם בחינה אוביקטיבית עם כלים מובנים היתה מביאה את החברה לאותה החלטה. אם כך, מדוע ישנן בעיות תוך כדי היישום.
התשובה היא - לא נכתב מפרט דרישות, גם אם אנחנו בטוחים מהו כלי ה- PLMשמתאים לנו, חשוב לעבוד מול מפרט דרישות מוגדר. ולמה זה חשוב ? הדבר חוסך ויכוחים בין הלקוח לבין מיישם ה- PLM. יתרה מזאת, מפרט דרישות חוסך ויכוחים פנימיים שמתגלים חדשות לבקרים תוך כדי הדיונים עם מיישם ה- PLM, כן, ידוע לי שגם כאשר יש מפרט דרישות מסודר יכולות להיות מחלקות בתוך צוות ה- PLMשל הלקוח ואז המיישם מטעם חברת ה- PLM יושב בפנים קפואות ואינו יודע איך להגיב. אם כך, מה היתרון במפרט דרישות מסודר. היתרון הוא אחד - מנהל הפרוייקט מטעם הלקוח יכול להצביע על נושאים שעולים ואינם תואמים את הדרישות ובעצם "לקרוא לסדר" את המתווכחים. במקרה זה גם למנהל הפרוייקט מטעם מיישם ה- PLMיש "מה להגיד". לעומת זאת אם אין מפרט כזה הרי שעובדים ב- "לופ פתוח" שבו כל דרישה היא פתח למו"מ נוסף ואין אני מכוון להיבט הכספי, אלא למו"מ הנדסי / טכני.
תשאלו אותי בודאי, כפי ששואלים אותי רבים מלקוחותי ואם אנחנו מגלים נושאים חדשים "תוך כדי תנועה", האם במקרה כזה נעלה לאוויר עם מערכת PLMחלקית / חסרה / צולעת (בחרו את המתאים).
התשובה היא פשוטה ונמצאת בתחום ניהול תצורה לתוכנה. במקרים שכאלה נידרש לפתוח SCR
(Software Change Request)במסגרת פרוייקט היישום של ה- PLMולדון בצוות הפרוייקט על מהות השנוי, חשיבותו ודחיפותו. כן נכון, פרוייקט PLM, כמו כל פרוייקט תוכנה ולמעשה כמו כל פרוייקט של פיתוח / תכנון אינו פטור מניהול תצורה.
מה באשר לאישור ה- SCRs? חלק מהם אומנם יאושר ליישום מיידי, אך רב רובם של ה- SCRsיידחה ל- Phase II, כלומר תחילה נעלה לאוויר ואחר כך נעשה "מקצה שיפורים".
מה לא תעשה במפרט דרישות ?
תחילה מילה אחת על ה- "כן", המפרט חייב להיות חד משמעי ולהקיף את כל הנושאים שחשובים לך הלקוח.
בכל זאת מה לא ? ראיתי כבר מפרט דרישות שבו נכתבו הצהרות כלליות כמו עמידה ב- MIL-STD-973
(תקן של משרד ההגנה האמריקאי לניהול תצורה). מאחורי אמירה כזו מסתתר עולם ומלואו, שחלק גדול מהאמור בתקן, אני משוכנע שהלקוח כלל לא התכוון. הסבתי את תשומת ליבו של הלקוח (במקרה זה הוא כבר היה לקוח שלי שביקש לעבור על מפרט הדרישות) לעובדה פשוטה, התקן מחייב הגדרה של פריטי תצורה, מעקב על פריטים אלה, בצוע הקפאות תצורה לכל פריט במסגרת סקרי תיכון ומבדקים (Configuration Audits). האם באמת התכוונת לזה ? הגמגום הקצר של נציג הלקוח הבהיר לי שהנושא כלל אינו נהיר להם. למעשה, כוונת הלקוח היתה לניהול מסודר של מסמכים ומהדורות על פי התקן, זהוי פריטים על פי התקן ויישום בקרת שנויים , אחרי סדרתי ראשון על פי התקן. אגב, גישת התקן לבקרת שנויים, היא שונה מהדרישה שהציג בפני הלקוח, ועל כך במסגרת דברי על ניהול תצורה. אני מקווה שברור לכם שמול דרישה שכזאת מיישם ה- PLMהיה לפני הכל מאוד נבוך. מבוכה זו היתה מתורגמת לאינסוף שאלות על מנת שהמיישם יבין מה עליו בעצם לעשות. לאור העובדה שמערכות ה- PLMאינן זהות, הרי שבמהלך השיג והשיח הזה בין מיישמים פוטנציאליים לבין הלקוח היה נוצר סחף של הדרישות, לפי דברי המיישמים.
הימנע מדרישות שהן Nice to Have, ואם בכל זאת אתה מעוניין לשלב אותם, או שאין ברירה, לדוגמא, גורם בכיר בארגון מאוד רוצה אותם, אזי תדאג לסווג את הדרישות לפי רמות, מי החשובות ביותר, בינוני ועדיפות נמוכה. ידוע לי מנסיון שלעיתים לא ניתן להימנע מדרישות שכאלה, אחרת מפרט הדרישות לא ייצא כלל. היו לי גם מקרים כאלה, לעיתים דרישות אלה הן לא בדיוק מתחום ה- PLMואזי נידרש לרבע את המעגל (אם לא הצלחנו לשכנע בצדקת הדרך).
איך נבחר את המערכת המתאימה ?
חשוב לבחון את חברות ה- PLMעל בסיס שוה, כלומר לפי תרחיש או פרמטרים שאתם קובעים למיישמי ה- PLM, אחרת ספק ה- PLMאו מיישם ה- PLMיתמקד בנושאים שהוא מרגיש בהם חזק ולאו דוקא בנושאים שהם מהותיים עבורכם. במקרה זה תנסו מדי פעם לקרוא לו לסדר, אבל ספק אם זה יעזור.
זיכרו לא קיימת מערכת ה- PLM"הטובה ביותר", תפקידכם הוא לבחור את המערכת המתאימה ביותר לדרישות הארגון ולאופי הפעילות, באופן טבעי, חברה מתחום ה- Medical Devicesתפעיל מערכת שיקולים שונה מחברה מתחום ה- A&D.
את מי נבחר לנהל את הפרוייקט ?
בחירת מנהל הפרוייקט יכולה להיות נושא בעייתי בארגון, יש שמאמינים שהמנהל צריך (או צריכה) להיות מה- Businessויש אחרים שלהם ברור להם, שמנהל פרוייקט ה- PLMחייב להיות מיחידת מערכות מידע ושלא קימת כלל אפשרות אחרת.
לעניות דעתי לנקודה זו אין חשיבות, על בסיס של כ- 55 פרוייקטים שבהם השתתפתי אישית אני יכול לציין שחשובה האישיות של המנהל, השפעתו בארגון ויכולתו הארגונית, הרי בסופו של דבר מנהל הפרוייקט לא ישלח מסמכים לסבב אישורים ב- PLMואם נעסוק בנושאים קצת יותר מהותיים הוא לא חייב להכיר את כל הניואנסים ההנדסיים ואת אלה של ניהול תצורה. מתוך אלה שעבדתי איתם היו הרבה מנהלי פרוייקט מוצלחים ומצליחים שהגיעו מה- Businessובמקרה זה מנהל הפרוייקט היה בדרך כלל מנהל ההנדסה או גורם בכיר בהנדסה, אך יחד עם זה יש לציין מנהלי פרוייקט טובים שהיו מתחום מערכות מידע.
לא להתעקש (לא בכל מקרה ולא בכל מחיר)
בשעה טובה, בחרנו את המערכת ואת המיישם של מערכת ה- PLM, יש לנו מנהל פרוייקט והתחלנו "לרוץ", כמובן על פי מתודולוגיה סדורה, הרי אנחנו מאוד מסודרים. כמו בכל פרוייקט מכובד במהלך הפרוייקט מתגלות בעיות החל מהעובדה שמיישם ה- PLMלא באמת הבין דרישה מסויימת ועכשיו צריך למצוא פתרון מעשי. במקרה כזה עדיף למצוא פתרון שנמצא ב- "ארגז הכלים" של ה- PLMולא להתעקש על קוצו של יוד, גם אם הפתרון לא יהיה מושלם כפי שדמינו.
סוג אחר של אתגרים הוא בעובדה וזה אומנם קרה לי באחד הפרוייקטים בשנים האחרונות, שחברת האם לא הצליחה לעמוד בהתחיבות לספק ממשק בין מערכת ה- PLMלאחת ממערכות התיב"מ. לשבחו של המיישם הישראלי יש לציין שהוא הציע לבנות ממשק פרי פיתוח מקומי שיוחלף בעתיד, עם קבלת הממשק הקבוע. מנהל הפרוייקט בהתיעצות איתי החליט שעדיף לא ליישם את הממשק בשלב הראשון של הפרוייקט , אלא להמתין לממשק OOTB(Out Of The Box). יש לציין שבפרוייקט היו ממשקי PLM - CADחשובים יותר ועל כן הויתור היה אפשרי. כמובן "שסיפור" מסוג זה אינו קביל בממשק בין ה- PLMל- ERP, גם מקרה כזה היה לי, אבל אז לא היתה ברירה אלא להתעקש על קבלת הממשק גם במחיר של דחייה בעלייה לאוויר.
המסקנה היא לא להתעקש עם מיישם ה- PLM, או לא להתעקש כלל, אם הנושא אינו קריטי.
