top of page

מסדרים בקופסאות. דיאגרמת ישויות - Business ERD

עודכן: 26 בספט׳ 2021


ראשית דבר

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


כשהתחלתי להשתמש ב Business ERD וצוותי הפיתוח שמעו את המונח ERD עמדו להם האוזניים,

הרי ERD הוא קיצור של Entity Relationship Diagram מונח שמתייחס לרוב להגדרות וניהול דאטה-בייס.

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

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



מי בכלל צריך Business ERD?

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


למה צריך Business ERD?

  1. כדי להגדיר את הישויות העסקיות בחברה/במוצר/בפיצ'ר שלכם.

  2. כדי להסביר את תכונותיה של כל ישות, מה היא כוללת וגם מה היא לא כוללת.

  3. כדי להסביר את הקשר בין ישויות העסקיות.

  4. תגלו לאורך זמן שהגדרה ברורה של הישויות מסייעת ומקלה את שלבי האפיון. "תעלו" על חורים בפתרון.

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

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

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


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

 

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

בואו נעמוד על ההבדל בין Business ERD לבין Business Flow


במקרה של Business flow diagram

  • נרצה לבטא תהליך מסוים (נאמר רישום משתמש לשירות, תהליך כניסה, תהליך רכישה)

  • אנחנו מציגים סטרימליינים בין מערכות או בין שירותים.

  • אנחנו מציירים קווים וחצים שמסמנים תנועה, התחלה וסוף של תהליך.

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




במקרה של Business ERD - דיאגרמת ישויות עסקיות

  • אנחנו מבטאים הגדרת ישות. מה משמעותה של כל ישות.

  • אנחנו לא מבטאים תהליך מסוים, תרשים ERD טוב אמור להכיל את כל התהליכים הקיימים. שימו לב שאין בתרשים פיצולי קבלת החלטה, IF Then וכו'

  • אנחנו מציירים את הקשר שבין הישויות ולא את התהליך שגורם לקשר להשתנות.

  • אנחנו מבינים מה כל ישות עושה, מחליטים מתי לפצל אותה ומה מעבר לאחריות של הישות.





 

איך זה עובד?

תהליך העבודה

  1. הכלי - קחו דף, לוח מחיק, השתמשו בכלים כמו MIRO, VISIO, Draw.io, או כל כלי שיודע לצייר ריבועים. הכלי באמת לא כל כך משמעותי כמו השיטה. וכמו חומוס כולם חושבים שהם משתמשים בהכי טוב.

  2. הכינו רשימה של מהן שלדעתכם הם ישויות החברה/המוצר/שירות.

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

  4. חפשו את הישות הראשונית ביותר, זאת שאינה תלויה באף ישות אחרת - ציירו ריבוע וכתבו את שמה.

  5. חפשו את הישות המשנית התלויה (או שלא) בקודמתה, ציירו ריבוע וכתבו את שמה, ציינו בחץ חד/דו צדדי את הקשר בין הישויות

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

  7. עכשיו עבור כל ישות כתבו את המאפיינים העקרים שלה, מהו המזהה שלה (למשל תעודת זהות כמזהה של משתמש או מספר סניף במקרה של חנות)

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

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

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

  11. סמנו באופן ממודל ישויות שכבר קיימות, מול ישויות עתידיות או ישויות בפיתוח Inhouse לעומת 3rd party service.


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

 



דוגמא לתהליך - AM:PM

*האמור ללא ידע טכני על החברה ויתכן שאינו מדויק כלל, הדוגמא מובאת רק לצורך תיאור התהליך


כך אני רואה את פירוט הישויות של AM:PM, ההסבר לכיוון החשיבה מתחת


  1. הישות סניף לדעתי היא הבסיסית ביותר, כי נראה שלא תלויה באף ישות אחרת (הרבה תלויות בה)

  2. אני מניח שגם הישות לקוח לא תלויה באף ישות (בהנחה שלקוח לא משויך לסניף קבוע)

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

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

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

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

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

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



עכשיו נפרט את כל אחת מהישויות, במשפט קצר מה משמעות הישות מבחנתינו

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


שאלה שעלתה לי למשל תוך כדי הכנת התרשים היא האם "כתובת" היא חלק מישות הלקוח או שהיא ישות אחרת, ההחלטה אם כך או כך תהיה תלויה בהחלטה מוצרית!

האם ללקוח יש כתובת אחת בלבד בזמן נתון - אז אין צורך בישות נפרדת

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





 

דוגמא לתהליך שני - Netflix

*האמור ללא ידע טכני על החברה ויתכן שאינו מדויק כלל, הדוגמא מובאת רק לצורך תיאור התהליך


כך אני רואה את פירוט הישויות של Netflix, ההסבר לכיוון החשיבה מתחת


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

  2. הישות הראשונית הנוספת שחשבתי עליה היא לקוח, אני חושב שהיא לא תלויה באף ישות אחרת.

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

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

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

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

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




בשלב הבא נפרט את משמעות כל אחת מהישויות

נכתוב במשפט אחד מה המשמעות העסקית שלה

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





 

לסיכום:

  1. אני ממליץ להשתמש בדיאגרמת Business ERD עבור כל מוצר. זאת פעולה יחסית מהירה.

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

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

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


באיזה כלי אתם משתמשים כדי לנתח, להבין ולשתף את הגדרות המוצר?

שתפו איתי





724 צפיות0 תגובות

רוצה לקבל עדכון בפרקים הבאים?

יש!, נתראה בפרק הבא

bottom of page