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

אישור מסמכים באפליקציית מובייל: היכן התהליך נשבר

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

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

גם כאשר במערכת כבר מותקן 1С:Документооборот, החלק הנייד מצטמצם לעיתים קרובות לצפייה בלבד: הקובץ נפתח, אך פעולה עליו אינה זמינה. אישור מהטלפון הופך ל"קראתי, אחזור — אחתום". צוואר הבקבוק כאן אינו בקישוריות ולא במסך, אלא בכך שהמסלול אינו מתואר כנתונים.

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

אפקט מדיד: מהירות החלטות ופחות החזרות לתיקון

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

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

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

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

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

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

את התממשקות בונים מול קו ניהול המסמכים האלקטרוני הקיים, כולל 1С:Документооборот, תוך שמירה על מסלולים, תפקידים והרשאות גישה שכבר אומצו.

אפשרויות מימוש: לקוח נייטיב, היברידי, פורטל ווב

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

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

שלבי ההטמעה: מניתוח מסלולים ועד מסירה לתמיכה

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

1. ביקורת מסלולי אישור. מנתחים את השרשרות הקיימות: מי יוזם, מי מאשר, מי מחתים, מה קורה בסירוב ובחלוף המועד. הפלט — מפת מעברי סטטוסים.

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

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

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

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

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

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

מה נשאר לכם לאחר ההשקה: קונפיגורציות ונהלים

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

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

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

מקרה בוחן: אישור חוזים מהטלפון תוך דקות

הלקוח — מפעיל לוגיסטי ТрансЛайн: עורכי דין במשרד הראשי, מנהלים מסחריים — באזורים ובאתרים. החוזים אושרו בדואר, הקובץ עבר בשרשרת של שישה משתתפים, ועד הסבב השלישי בהתכתבות חיו ארבע גרסאות שונות של אותו מסמך.

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

מה שינו במסלול

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

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

מדדים לפני ואחרי

החציון של מחזור אישור החוזה התקצר מ-7 ימי עבודה ל-1.5. שיעור ההחזרות לתיקון ירד מ-34% ל-11% — הודות לענפים מקבילים ולקונפליקט גרסאות מוקדם, ולא ל"האצה לשם האצה".

גרסאות שאבדו נעלמו כסוג: היומן מתעד מי ומה שינה בכל סעיף, וזה מסיר את הוויכוחים "אישרנו גרסה אחרת". החריגה מהנורמה השבועית הפנימית ירדה מ-22% ל-3%.

לקוח נייטיב או פורטל ווב: מה לבחור במקרה שלכם

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

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

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

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

אנו בוחרים אפשרות לפי שיעור הפעולות מחוץ למשרד וקריטיות החתימה הלא מקוונת — זה נראה מיומן האישורים, ולא לפי משאלות לממשק.

שאלות נפוצות בנושא אינטגרציה, הרשאות גישה והגנה

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

מי ואילו מסמכים יראה?

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

מה קורה אם אין רשת?

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

כיצד מוגנים הנתונים במכשיר עצמו?

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

מה כלול בתמיכה לאחר ההשקה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

מה נדרש מכם להערכה ולתוכנית העבודה:

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

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