פיתוח מערכת AI לאוטומציה של ניהול כוח אדם

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

אוטומציה של ניהול כוח אדם: היכן התהליך הידני נשבר

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

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

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

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

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

מה נותנת מערכת AI במעגל משאבי האנוש

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

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

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

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

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

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

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

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

גישות להטמעה: שירות ענן, מתאר מקומי, היברידי

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

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

מה בודקים לפני הבחירה

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

כיצד בוחרים בפועל

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

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

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

  1. ביקורת תהליכי משאבי אנוש. אנו אוספים רשימת פעולות: קליטה, העברה, חופשות, מחלה, נסיעות עסקים, סיום העסקה. עבור כל אחת אנו מתעדים את מסמכי הקלט, המשתתפים, המועדים על פי חוק ותקנות פנימיות, וכן את המקומות שבהם מתבזבז כיום זמן — העברה ידנית בין מערכות, הקלדה חוזרת, המתנה לחתימה.
  2. תכנון סכימת הנתונים. אנו מגדירים מה נחשב לישות ומה לנגזרת: עובד, מחלקה, תפקיד, סוג היעדרות, מסמך-בסיס. אנו מתאמים מפתחות וכללי עדכון שלהם, כדי שהמערכת לא תיצור כפילויות ולא תסתור את מערכת החשבונאות.
  3. הגדרת כללים. אנו מנסחים באופן פורמלי את מה שקודם לכן היה קיים רק בראש: למי נשלחת הבקשה, מי מאשר, באילו תנאים נוצרת ההחלטה, אילו מועדים מפעילים תזכורת. את הכללים אנו מתארים במפורש ומנהלים בגרסאות — בעת שינוי התקנון נערכת התצורה, ולא הקוד.
  4. בדיקה על נתונים היסטוריים. אנו מריצים את הכללים החדשים על תקופות סגורות ומשווים את התוצאה לזו שהוגשה ידנית. פערים מנותחים עד לשורשם: או שהכלל תואר באופן חלקי, או שבנתוני העבר קיים חריג שיש להתחשב בו.
  5. הפעלה ניסיונית בהיקף מוגבל. אנו מפעילים במחלקה אחת או בסוג פעולות אחד, תוך שמירה על בקרה ידנית במקביל. כך תקלות נראות לפני שהן משפיעות על כל זרימת המסמכים.
  6. הדרכת עובדים ותקנון עבודה. אנשי משאבי האנוש והמנהלים מקבלים הנחיות בהתאם לתפקידיהם: מה לעשות במערכת, מה נותר על הנייר, ולמי לפנות במקרה של חריגה.
  7. מסירה להפעלה. אנו מתעדים את הרכב הכללים, סכימת הנתונים, סדר עדכון המפתחות ונקודות הבקרה. מכאן המערכת ממשיכה לפעול בצד שלכם, והשינויים מבוצעים לפי נוהל ברור.

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

מדיניות גישה והפרדת הרשאות במערכת משאבי אנוש

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

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

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

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

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

מה הלקוח מקבל לידיו לאחר ההטמעה

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

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

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

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

במה שונה עיבוד AI של בקשות מניהול מסמכים קלאסי?

ניהול מסמכים קלאסי עובד עם מה שכבר הובא לצורה מובנית: כרטיס עובד, שדות הבקשה, מסלול אישור. מערכת לניהול מסמכים אלקטרוניים שומרת קובץ ומניעה אותו במסלול שהוגדר מראש, אך אינה מבינה את התוכן — אם שדה לא מולא ידנית, הוא просто יישאר ריק.

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

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

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

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

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

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

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

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

מה שינו

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

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

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

מדד לפני אחרי
זמן עיבוד ממוצע לבקשה 2-3 ימים 4-6 שעות
שיעור בקשות עם הבהרות ~40% 8-12%
שגיאות בחישובים קבועות, התגלו בדיעבד בודדות, נתפסות בכניסה
עומס על המומחה העברת נתונים ידנית בדיקה והחלטה לגופו של עניין

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

האם המערכת תואמת למערכת החשבונאית שלנו או שנצטרך להחליף אותה?

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

עד כמה זה בטוח לנתונים אישיים?

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

עד כמה קשה להטמיע את זה בתהליכים הקיימים?

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

כמה זמן נמשכת ההטמעה ומה קורה לאחר ההשקה?

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

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

נדון במשימת האוטומציה שלך לניהול תיקי כוח אדם

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

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

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

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