apple-touch-icon-144-precomposed

פיתוח מיזמים אינטרנטיים

058-4481-366

איך מכינים אפיון מערכת מידע מבלי לאבד שפיות בדרך?

אפיון מערכת

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

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

אז ממה מתחילים?

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

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

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

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

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

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

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

התוצר – מפת מצב מפורטת ומוסברת בשפה של המזמין שלכם – בשפה של משתמש קצה.

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

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

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

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

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

לפגישת ייעוץ, ללא עלות וללא התחייבות

התקשרו עכשיו
058-4481366

חלקים חשובים באפיון:

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

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

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

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

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

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

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

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

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

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

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

לפגישת ייעוץ, ללא עלות וללא התחייבות

התקשרו עכשיו
058-4481366

אנו כאן בשבילכם, אל תחכו התקשרו עכשיו 058-4481366