פורטל ארגוני: אינטראנט, פורטל עובדים ופורטל ספקים

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

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

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

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

Microsoft מגדירה בתיעוד שלה פורטל כאתר באינטראנט שיש בו הרבה צופים ומעט כותבים, ומציינת שבארגון גדול יכולים להיות כמה כאלה, למשל פורטל חברה ופורטל משאבי אנוש (Creating and launching a healthy SharePoint portal). זו הגדרה טובה לאינטראנט, אבל היא מתארת רק חלק מהתמונה. פורטל ספקים או פורטל לתושבים הפוך לגמרי: בו הקהל הוא שמייצר את רוב התוכן, בטפסים, במסמכים ובפניות, והארגון הוא שקורא ומטפל.

שלושה פורטלים, שלושה קהלים

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

אינטראנט ופורטל עובדים

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

פורטל ספקים

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

פורטל שירות עצמי ללקוחות או לתושבים

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

מתי באמת צריך פורטל, ומתי מספיק פחות

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

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

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

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

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

Microsoft 365 ו-SharePoint

אם הארגון כבר עובד ב-Microsoft 365, ההזדהות, ספריית המשתמשים, המסמכים וה-Teams כבר שם, ו-SharePoint הוא נקודת הפתיחה הטבעית לאינטראנט. Microsoft ממליצה להשתמש באתר תקשורת (Communication site) לפורטל, עם עמוד אתר כעמוד הבית, ולשמור את אתרי הצוות (Team sites) לשיתוף פעולה בתוך קבוצות. אתר בית (Home site) משמש כעמוד הנחיתה של האינטראנט, ואתרי רכזת (Hub sites) מחברים משפחות של אתרים עם ניווט משותף, חיפוש משותף ומיתוג אחיד (Planning your SharePoint hub sites).

הנקודות החזקות: אין צורך להקים זהות חדשה, ההרשאות מנוהלות במקום אחד, מסמכים לא משוכפלים, והכלים מוכרים לעובדים. הנקודות החלשות: חופש עיצוב מוגבל יחסית, תהליכים מורכבים דורשים פיתוח בתוך הסביבה של Microsoft, וקהל חיצוני גדול הוא סיפור אחר. שיתוף חיצוני ב-SharePoint נועד לשיתוף פעולה עם שותפים ואורחים, והוא מופעל כברירת מחדל ברמת הארגון כולו. Microsoft עצמה ממליצה לשקול לכבות אותו עד שמחליטים איך להשתמש בו, ולשמור מידע רגיש באתר שבו השיתוף החיצוני כבוי (Overview of external sharing). לאתרים חיצוניים עם קהל רחב Microsoft מציעה מוצר נפרד, Power Pages, שמוגדר בתיעוד שלה כפלטפורמה לבניית אתרים עסקיים שפונים החוצה, על בסיס הנתונים Dataverse (What is Power Pages).

פורטל על מערכת תוכן

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

אפליקציה בפיתוח מותאם

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

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

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

כניסה אחת, Single Sign-On, פירושה שהמשתמש מזדהה פעם אחת מול ספק הזהות של הארגון, ומשם נכנס לפורטל ולמערכות המחוברות בלי סיסמה נוספת. Microsoft מסבירה שעם SSO האפליקציות כבר לא צריכות לנהל שמות משתמש וסיסמאות משלהן, ושיש פחות בקשות לאיפוס סיסמה שמגיעות למוקד התמיכה (What is single sign-on in Microsoft Entra ID). מבחינת אבטחת מידע, היתרון הגדול הוא אחר: כשעובד עוזב, מכבים לו חשבון אחד, והגישה לכל המערכות נסגרת יחד.

שני התקנים שצריך לדרוש במפרט

SAML 2.0 הוא תקן של ארגון התקינה OASIS, שאושר כתקן ב-1 במרץ 2005, ומגדיר איך מעבירים בין מערכות הצהרות על זיהוי, תכונות והרשאות בפורמט XML (OASIS: SAML v2.0). OpenID Connect הוא שכבת זהות מעל פרוטוקול OAuth 2.0, והגרסה הנוכחית של מסמך הליבה שלו היא OpenID Connect Core 1.0 עם סט התיקונים השני, מדצמבר 2023 (OpenID Connect Core 1.0). Microsoft מתארת את SAML כמתאים לאפליקציות ווב מסורתיות ולמערכות ארגוניות ותיקות, ואת OpenID Connect כמתאים לאפליקציות ווב מודרניות, לאפליקציות לנייד ולממשקי API. בפורטל חדש שווה לדרוש תמיכה בשניהם, או לפחות לדעת מה ספק הזהות שלכם תומך.

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

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

אם הפורטל מחזיק מידע אישי, ובדרך כלל הוא מחזיק, תקנות הגנת הפרטיות (אבטחת מידע), התשע״ז-2017 רלוונטיות ישירות. תקנה 8 קובעת שבעל מאגר מידע יקבע הרשאות גישה בהתאם להגדרות תפקיד, שהרשאה לכל תפקיד תהיה במידה הנדרשת לביצוע התפקיד בלבד, ושינוהל רישום מעודכן של התפקידים, ההרשאות ובעלי ההרשאות. תקנה 10 דורשת במאגרים ברמת אבטחה בינונית או גבוהה מנגנון תיעוד אוטומטי של הגישה, שנתוניו נשמרים לפחות 24 חודשים (נוסח התקנות בנבו, נכון לאוקטובר 2026). איזו רמת אבטחה חלה על המאגר שלכם היא שאלה לממונה אבטחת המידע וליועץ המשפטי, אבל המשמעות לתכנון ברורה: ההרשאות מתוכננות לפי תפקידים מההתחלה, ויומן הגישה הוא דרישה ולא אפשרות.

נקודה אחת שמפתיעה ארגונים שעוברים ל-SharePoint: שיוך אתר לרכזת לא משנה את ההרשאות שלו. Microsoft מבהירה שהמידע שמוצג ברכזת מסונן לפי הרשאות, ומי שאין לו גישה לתוכן לא יראה אותו (Planning your SharePoint hub sites). זה טוב לאבטחה, אבל זה גם אומר שאם ההרשאות באתרים עצמם מבולגנות, הרכזת לא תסדר אותן.

ממשל תוכן: לכל עמוד יש בעלים

Microsoft כותבת בתיעוד תכנון האינטראנט משפט ששווה לתלות על הקיר: אם המשתמשים מתלוננים שהחיפוש לא עובד כי הוא מוצא יותר מדי תוכן לא רלוונטי, זה יכול להעיד על בעיית ממשל ולא על בעיה בחיפוש. ההמלצה שם היא להחליט על כללי הממשל מוקדם, כי קל יותר לקבוע ולאכוף אותם בתחילת הפרויקט (Plan an intelligent SharePoint intranet).

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

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

חיפוש וניווט: למצוא בלי לדעת איפה

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

כמה כללים שעובדים בכל פלטפורמה:

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

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

נייד ועובדים בשטח

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

ב-Microsoft 365 הכלי לכך הוא אפליקציית SharePoint בתוך Teams, שנקראה בעבר Viva Connections. לפי התיעוד, היא בנויה על אתר הבית של SharePoint, נגישה מאפליקציית Teams במחשב, בטאבלט ובנייד או מהדפדפן, וכוללת לוח מחוונים עם כרטיסים שבהם אפשר לבצע פעולות כמו דיווח תחילת משמרת או גישה לחומרי הדרכה. התיעוד מציין גם שמשתמשים עם מנוי Microsoft 365 רגיל מוגבלים לחוויה אחת, ושיותר מאחת דורשת רישוי Viva נוסף לכל משתמשי הארגון (Overview: SharePoint app in Teams, נכון לאוקטובר 2026). את תנאי הרישוי המדויקים שחלים עליכם מאמתים מול ספק הרישוי של הארגון.

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

אינטגרציות: HR, ERP, CRM וטפסים

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

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

נגישות, פרטיות ואבטחת מידע

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

נגישות

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

פרטיות

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

אבטחת מידע

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

אימוץ: פיילוט, השקה בגלים ושגרירים

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

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

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

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

איך מודדים שהפורטל עובד

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

ב-SharePoint, נתוני השימוש של אתר כוללים צופים ייחודיים, ביקורים, זמן ממוצע למשתמש, תוכן פופולרי ופילוח לפי מכשיר ולפי שעה, בטווחים של 7, 30 ו-90 ימים ברוב המדדים (View usage data for your SharePoint site, נכון לאוקטובר 2026). זה מספיק כדי לדעת אם אנשים נכנסים. כדי לדעת אם הפורטל עובד, צריך לחבר את המספרים האלה למה שקורה מחוץ לו.

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

מפרט לפורטל: רשימה להדבקה

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

מה עושים עכשיו

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

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

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