מודל הנתונים שמאחורי משרד עורכי דין: תיק כמפתח יחיד, רישום שעות שנתפס בזמן אמת, אירוע יומן שמחובר לתיק ומסמך שנכנס עם ערוץ מקור ידוע. תיאור טכני בלבד.
עיקרי הדברים
- מזהה התיק הוא המפתח היחיד במשרד. אירוע יומן, שעה או מסמך בלי מזהה תיק הם נתון יתום, ולא יופיעו באף דוח.
- שעה שנתפסה בזמן אמת ושעה ששוחזרה בסוף החודש הן שני סוגי נתונים. צריך שדה שמבדיל ביניהם.
- דגל הרשאה על תיק הוא מנגנון גישה טכני. הוא אוכף מי רואה רשומה, ולא יותר מזה.
- כל תאריך במערכת הוא תאריך שמישהו הקליד. המערכת אינה מחשבת מועדים ואינה מסיקה מהם מסקנה.
- המדד המשמעותי היחיד הוא אחוז הרשומות שנוצרו כשהן כבר מקושרות לתיק.
מערכת של משרד עורכי דין שומרת ארבעה אובייקטים בלבד: תיק, רישום שעה, אירוע יומן ומסמך. כל השאר הוא תצוגה מעליהם. האוטומציה מחברת את שלושת האחרונים למזהה התיק ברגע היצירה, ולא בסוף החודש. היא רושמת מה קרה ומתי, ואינה מכריעה דבר.
זהו תיאור טכני של נתונים ותהליך עבודה, ולא ייעוץ משפטי ולא הנחיה לניהול הליך.
ארבעת האובייקטים שהמערכת באמת שומרת
לכל אובייקט יש מפתח משלו ויחס מוגדר לתיק:
- תיק.
matter_idהוא המפתח הראשי, ולצידו לקוח, עורך דין אחראי, תאריך פתיחה, סטטוס והסדר חיוב. שם התיק אינו מפתח, כי שמות משתנים. - רישום שעה.
entry_id, ובתוכוmatter_id, מבצע, חותמת התחלה, משך בדקות, תיאור פעולה, דגל חיוב ומקור הרישום. - אירוע יומן. מזהה
UIDיציב לפי תקן iCalendar, שדהmatter_idשיכול להיות ריק, משתתפים, והתכונותSEQUENCEו-RECURRENCE-IDשמאפשרות להבדיל בין אירוע שעודכן לבין מופע בודד בסדרה שהוזז. - מסמך.
doc_id,matter_id, חותמת קליטה, ערוץ מקור, שם הקובץ המקורי וטביעת גיבוב שתופסת כפילויות.
היחסים פשוטים: לתיק אחד יש רבים מכל השאר, ולכל אחד מהשאר יש תיק אחד לכל היותר. ברגע שרשומה רשאית להתקיים בלי תיק, נולדה קטגוריה חמישית שאף אחד לא סוגר.
למה שעה שנרשמה בסוף החודש היא נתון אחר משעה שנתפסה בזמן אמת?
כי מקור הרישום קובע את רמת הדיוק שלו, ובלי שדה source אי אפשר לדעת במה מסתכלים. שלושה מקורות מייצרים שלוש איכויות:
- טיימר חי. חותמות התחלה וסיום אמיתיות. המשך אינו מעוגל, והתיאור נכתב בזמן הפעולה.
- הקלדה ידנית בסוף היום. המשך כמעט תמיד מעוגל לרבע שעה, והתיאורים מתקצרים.
- גזירה מאירוע יומן. מדויק מול לוח הזמנים, אבל מודד את מה שתוכנן ולא את מה שקרה.
שמירת source על כל רישום היא ההבדל בין דוח שאפשר להסביר לבין דוח שמתווכחים עליו. אותה הפרדה בין מתוכנן לבין בוצע מופיעה גם במעקב שעות, אבני דרך ותקציב.
אילו שדות בתיק נושאים משקל, ואילו הם לתצוגה בלבד?
| שדה | סוג | למה הוא קיים |
|---|---|---|
matter_id | מזהה יציב | המפתח שכל רשומה אחרת מצביעה אליו |
client_id | הפניה | מפריד בין הלקוח לתיק, כי ללקוח אחד יכולים להיות כמה תיקים |
status | רשימת ערכים סגורה | פתוח, מושהה, סגור. טקסט חופשי כאן שובר כל דוח |
responsible_user | הפניה | בעלים אחד, גם כשצוות שלם עובד על התיק |
billing_arrangement | רשימת ערכים סגורה | לפי שעה, סכום קבוע, או ללא חיוב |
opened_at | תאריך | תאריך פתיחה שהוקלד, אף פעם לא כזה שחושב |
access_flag | דגל | האם התיק מוגבל לקבוצת משתמשים מוגדרת |
matter_name | טקסט חופשי | לתצוגה בלבד, ולעולם לא מפתח |
השורה האחרונה נשברת ראשונה. משרדים מזהים תיק לפי מחרוזת כמו שם הלקוח ושנה, ואז מישהו מתקן שגיאת כתיב ושתי שנות רישומים מתנתקות זו מזו.
מה דגל ההרשאה עושה, ומה הוא לא מכריע
access_flag הוא מנגנון טכני שמצמצם את קבוצת המשתמשים שרואה רשומה. יש לו שלוש השפעות מדידות:
- הוא מסנן את התיק מרשימות, מחיפוש ומדוחות עבור כל מי שאינו ברשימת ההרשאות.
- הוא מחיל את אותו סינון גם על אירועי היומן, השעות והמסמכים שמקושרים לאותו תיק, אחרת ההגבלה דולפת דרך הדוחות.
- הוא נכתב ליומן ביקורת: מי שינה, מתי, וממה למה.
מה שהוא אינו עושה: הוא אינו קובע מי צריך להיות מוגבל, ואינו מחליף החלטה אנושית בשאלה הזו. המערכת אוכפת רשימה שמישהו הזין לתוכה.
איפה המודל נשבר בפועל
- אירוע יומן בלי תיק. הפגישה נקבעה מהטלפון, לא עברה דרך המערכת, והזמן שלה לא מופיע בשום דוח תיק.
- מופע יחיד בסדרה שהוזז. בלי
RECURRENCE-IDהעדכון נוחת על כל הסדרה, ושלושה תיקים אחרים מזיזים שעה בלי שאיש ביקש. - מסמך שנכנס דרך צ׳אט. הוא חי בטלפון של מי שקיבל אותו, בלי
doc_id, בלי חותמת קליטה ובלי ערוץ מקור. - עריכה של רישום נעול. מישהו מתקן רישום בחודש סגור, ודוח שכבר יצא ללקוח מפסיק להסתדר. תיקון צריך להיות רשומה חדשה עם הפניה, לא עריכה במקום.
- אותו לקוח פעמיים. נפתח
client_idשני מול אותו ח"פ, וכל דוח ברמת לקוח מציג חצי תמונה. - תיאור פעולה ריק. הרישום קיים אבל אין בו תוכן, וחודשיים אחר כך אף אחד לא יכול לאשר אותו.
שלושה דוחות שהמודל חייב לדעת להפיק
מודל נתונים נבחן בשאלה אילו דוחות אפשר להפיק ממנו בלי הקלדה נוספת. שלושה דוחות מכסים כמעט את כל הצורך היומיומי במשרד, ושלושתם נשענים על אותו מזהה תיק:
- שעות לפי תיק ולפי תקופה, בפילוח לפי מבצע ולפי דגל חיוב, כדי לראות מה נעשה ומה ניתן לחיוב.
- רשומות שאינן מקושרות לתיק, בחתך של אירועי יומן, שעות ומסמכים. זהו הדוח היחיד שמודד את בריאות המודל עצמו.
- תנועה בתיק בחודש האחרון: מתי נגעו בו לאחרונה, מי, ובאיזה סוג רשומה. תיק שלא זזה שישה שבועות אינו בהכרח בעיה, אבל הוא צריך להיות גלוי.
דוח רביעי, יומן שינויים ברמת הרשומה, אינו דוח תפעולי אלא תשתית: בלעדיו אי אפשר להסביר למה מספר בדוח שכבר יצא השתנה.
מה צריך להיות סגור לפני שבונים
- מאיפה מגיע
matter_id, ומי רשאי לפתוח תיק חדש. - רשימה סגורה של ערכי
statusושל סוגי הסדר חיוב, כולל מה קורה לרישומים כשתיק נסגר. - כלל נעילה: מאיזה מועד חודש סגור לעריכה, ואיך נראה תיקון אחריו.
- ערוץ קליטה יחיד למסמכים, כך שלכל מסמך יש ערוץ מקור מתועד. אישורים חתומים נשמרים לפי אותו היגיון של ראיה לחתימה דיגיטלית.
- מי הבעלים של רשומות יתומות, ומה קורה להן אחרי שבוע.
מקורות
שאלות נפוצות
האם המערכת יכולה לחשב לבד מועדים בתיק?
לא, ואין כאן המלצה שתעשה זאת. המערכת שומרת תאריכים שמישהו הזין ומציגה אותם. מה שתאריך אומר בתיק הוא שיקול דעת מקצועי, והתפקיד היחיד של התוכנה הוא להציג את מה שנרשם, למי שאחראי, בזמן.
מה ההבדל בין לקוח לבין תיק במודל הנתונים?
לקוח הוא הישות שמזוהה בח"פ או בת"ז ונושאת את פרטי החיוב. תיק הוא יחידת עבודה אחת עם עורך דין אחראי, סטטוס והסדר חיוב משלה. ללקוח אחד יכולים להיות כמה תיקים במקביל, ולכן איחוד השניים שובר כל דוח נפרד.
למה כדאי לשמור שדה מקור על כל רישום שעה?
כי הוא מסביר את איכות הנתון. טיימר חי, הקלדה בסוף היום וגזירה מהיומן מייצרים דיוק שונה לגמרי. בלי השדה הזה דוח שעות נראה אחיד, וכל דיון עליו הופך לוויכוח על זיכרון במקום על נתון.
מה עושים עם אירוע יומן שאין לו תיק?
משאירים אותו גלוי בתור ייעודי עם בעלים, ולא משייכים אותו לתיק לפי ניחוש. אירוע פנימי לגיטימי יישאר בלי תיק לתמיד, ולכן צריך סטטוס שמסמן שנבדק. שיוך אוטומטי לפי שם משתתף מייצר שעות בתיק הלא נכון.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.