לפני הפיתוח, להבין את העסק

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

העיצוב.

המודולים.

היכולות.

בקרות הגישה.

הדוחות.

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

להבין איך העסק באמת עובד.

כי פלטפורמה יכולה להיראות טוב ועדיין לא לייצג את הפעילות שהיא אמורה לתמוך בה.

הלוגיקה העסקית קודמת לכול

לכל חברה יש דרך פעולה משלה.

יש תהליכים שמתנהלים לפי שלבים מוגדרים.

יש כללים שתלויים בתנאים מסוימים.

למשתמשים יש הרשאות שונות.

יש מידע שצריך להופיע רק בזמנים מסוימים.

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

כל זה קיים עוד לפני שהוא הופך לטכנולוגיה.

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

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

חשבו על משהו יומיומי כמו רישום של אדם לפלטפורמה.

במבט ראשון, זה עשוי להיראות כמו טופס.

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

איזה מידע צריך לבקש?

אילו שדות הם חובה?

מה קורה אחרי ההרשמה?

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

למה הוא יכול לגשת?

אילו תהליכים מופעלים אוטומטית?

היכולת הגלויה עשויה להיות פשוטה.

הלוגיקה שמאחוריה – לא בהכרח.

תכנון טכנולוגיה פירושו גם לשאול שאלות

לפני שבונים, צריך להבין.

מה קורה קודם?

מה תלוי במה?

מי רשאי לבצע כל פעולה?

מה קורה כשתנאי מסוים לא מתקיים?

איזה מידע צריך כל תפקיד?

אילו תהליכים דורשים התערבות אנושית?

מה אפשר להפוך לאוטומטי?

אילו חריגים קיימים?

השאלות האלה עוזרות להפוך רעיון כללי לפעילות שאפשר לייצג בתוך מערכת.

גם החריגים הם חלק מהעסק

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

אבל הפעילות היומיומית כמעט אף פעם לא עובדת רק כך.

יש מקרים מיוחדים.

תנאים משתנים.

מצבים שדורשים בדיקה.

עסקאות שלא עוקבות בדיוק אחר הזרימה הראשית.

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

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

הפיתוח צריך הקשר

צוות טכנולוגי יכול לבנות יכולת.

אבל כדי לבנות את היכולת הנכונה, הצוות צריך להבין למה היא קיימת.

מי משתמש בה.

איזו בעיה היא פותרת.

איזה מידע היא מקבלת.

איזה מידע היא מפיקה.

ואיך היא מתחברת לשאר הפעילות.

ההקשר הזה משנה את האופן שבו הפיתוח מתבצע.

המשימה כבר אינה רק לבצע בקשה.

היא להבין את התפקיד שהבקשה הזאת ממלאת בעסק.

פלטפורמה משקפת גם החלטות עסקיות

כל הרשאה משקפת החלטה.

כל זרימת עבודה משקפת סדר עדיפויות.

כל אוטומציה משקפת כלל.

כל דוח משקף צורך במידע.

לכן פלטפורמה היא יותר מאוסף של כלים.

היא יכולה גם לייצג את האופן שבו חברה מאורגנת.

ככל שהארגון הזה ברור יותר, כך התרגום שלו לטכנולוגיה יכול להיות קוהרנטי יותר.

לבנות טוב יותר יכול גם להיות להבין טוב יותר

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

כשהוא מתחיל בפעילות, השיחה משתנה.

הצוות בוחן מה צריך לקרות.

למה זה קורה.

מי מעורב.

איזה מידע נכנס לתמונה.

ואיזו תוצאה זה צריך להפיק.

ההבדל הזה עשוי להיראות קטן בהתחלה.

אבל הוא יכול להשפיע על כל מה שנבנה אחר כך.

מחשבות לסיכום

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

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

לפני שמעצבים מסך, כדאי להבין את התהליך.

לפני שהופכים פעולה לאוטומטית, כדאי להבין את הכלל.

לפני שבונים יכולת, כדאי להבין את מטרתה.

כי פיתוח טכנולוגיה עבור חברה הוא לא רק יצירת כלים.

הוא תרגום של פעילות אמיתית למבנה דיגיטלי שיש בו היגיון.