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

פיתוח פורטל לבית מרקחת: היכן נשברת לוגיקת ההזמנה

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

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

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

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

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

מה נותן פורטל עם קטלוג והזמנה מראש

חיפוש התרופה הנדרשת תוך שניות, ולא תוך שיחת טלפון

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

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

הזמנה מראש ללא שיחת טלפון ושיעור אישורים צפוי

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

העומס על המוקדנים פוחת בפניות שגרתיות

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

ניהוליות במקום התאמות ידניות

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

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

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

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

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

מדוע שכבת הביניים בדרך כלל מנצחת

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

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

מה פותרים בשלב התכנון

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

איך אנחנו בונים את הפורטל: שלבי העבודה

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

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

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

מה הלקוח מקבל לידיו

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

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

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

קייס: פורטל לרשת בתי מרקחת עם חיפוש גיאוגרפי

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

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

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

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

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

במה שונה הזמנה מהקצאה בפורטל בית מרקחת?

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

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

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

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

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

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

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

ספקות טכניים נפוצים

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

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

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

מה עם התמיכה לאחר ההשקה — האם יהיה צורך להמתין שבועות לתיקונים?

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

האם ניתן להרחיב את הפורטל מאוחר יותר — להוסיף משלוחים, תוכנית נאמנות, רשת שנייה?

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

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

נדון במשימה של הפורטל שלכם

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

מה כדאי להכין לשיחה:

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

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