WEBVTT

00:00:00.000 --> 00:00:07.840
מוכנים למד מינוס עשרה ימים של Microsoft 365, Copilot, בינה מלאכותית, Azure, והאנשים שמעצבים את עתיד העבודה.

00:00:08.020 --> 00:00:12.240
בינואר הקרוב, M365 קון חוזרת ובגדול.

00:00:12.520 --> 00:00:18.460
הצטרפו אלינו למפגשים חיים, הדגמות מהשטח וידע פרקטי ממומחי תוכן וMVPS מכל העולם.

00:00:18.700 --> 00:00:23.900
בלי מצגות גנריות, בלי מילים ריקות מתוכן, אנחנו מתמודדים עם האתגרים האמיתיים.

00:00:23.900 --> 00:00:29.180
Copilot Studio, סוכני AI, Fabric, אבטחה, ממשל ואוטומציה.

00:00:29.180 --> 00:00:34.960
בין אם אתם אנשי אית, מפתחים או מובילים עסקיים, יש לנו מפגשים שתפורים עבורכם.

00:00:35.380 --> 00:00:40.460
במהלך עשרה ימים מלאים, תוכלו לחקור טכנולוגיות רבות ולהתחבר לקהילה גלובלית.

00:00:40.740 --> 00:00:44.720
צפו בשידור חי וקחו תובנות מעשיות בחזרה לארגון שלכם.

00:00:45.000 --> 00:00:49.280
ינואר 2027, עשרה ימים, קהילת Microsoft 1.

00:00:49.540 --> 00:00:50.900
ההרשמה פתוחה כעת.

00:00:51.700 --> 00:00:53.500
הבטיחו את מקומכם עוד היום.

00:00:54.980 --> 00:00:58.020
זה קורה ב-M365 קון נקודה נה.

00:00:59.180 --> 00:01:04.820
הצטרפו עכשיו ל-M365 קון נקודה נט ונתראה בשידור חי בינואר.

00:01:04.940 --> 00:01:08.520
תהיתם פעם אם הנתונים שלכם יכולים לפעול מבלי שתצטרכו לגעת בהם.

00:01:08.640 --> 00:01:11.040
דמיינו שאתם מזהים ירידה במלאי בזמן אמת.

00:01:11.200 --> 00:01:13.460
ובמקום לשלוח אימייל או לבדוק לוח מכוונים,

00:01:13.720 --> 00:01:16.160
המערכת שלכם פשוט מזמינה את המלאי עבורכם.

00:01:16.360 --> 00:01:17.600
זה לא תרחיש היפותטי.

00:01:17.760 --> 00:01:19.900
זה Fabric Data Activator בפעולה.

00:01:19.900 --> 00:01:25.440
היום נחבר בין נתונים גולמיים, התראות מיידיות ותגובות אוטומטיות.

00:01:25.720 --> 00:01:28.160
ונראה לכם איך זה משתלב עם Power By,

00:01:28.500 --> 00:01:32.960
Synapse ושאר Microsoft Fabric כדי להפוך תובנות לפעולה ללא דיחוי.

00:01:33.460 --> 00:01:35.960
החוליה החסרה בלולאת הנתונים שלכם.

00:01:35.960 --> 00:01:38.700
רוב הצוותים יגידו שהם פועלים בזמן אמת,

00:01:38.940 --> 00:01:40.620
אבל ברגע שמסתכלים לעומק,

00:01:40.820 --> 00:01:43.160
הכל מרגיש הרבה יותר כמו יום למוחרת.

00:01:43.400 --> 00:01:46.800
לוחות מכוונים מתרעננים כל 15 דקות, 30 דקות,

00:01:47.000 --> 00:01:48.300
ולעיתים רק פעם בשעה.

00:01:48.400 --> 00:01:51.300
עד אז, הדפוס שהייתם צריכים לתפוס כבר השתנה.

00:01:51.560 --> 00:01:55.580
והדוח שאתם רואים הוא יותר ניתוח שלאחר המשחק מאשר עדכון חי.

00:01:55.720 --> 00:01:59.100
אתם צופים בתיאור המהלכים אחרי שהמשחק כבר נגמר.

00:01:59.560 --> 00:02:02.060
הבעיה היא לא שכלי ביי לא מראים לכם מה קורה.

00:02:02.220 --> 00:02:03.900
הם בדרך כלל טובים מאוד בזה.

00:02:03.900 --> 00:02:06.760
החלק החסר הוא מה קורה אחרי שרואים את זה.

00:02:07.180 --> 00:02:11.360
כרגע, רוב תהליכי העבודה מסתמכים על אדם שיבחין בשינוי,

00:02:11.620 --> 00:02:14.320
יחליט איזו פעולה לנקות, ואז יבצע אותה.

00:02:14.500 --> 00:02:15.920
זה יוצר צוואר בקבוק.

00:02:16.180 --> 00:02:19.200
אפילו פעולה בסיסית כמו שליחת אימייל ללקוחות,

00:02:19.280 --> 00:02:21.980
כשמדד מסוים יורד הופכת למשימה הידנית,

00:02:22.280 --> 00:02:25.580
כי המערכת לא מוגדרת לחבר את התובנה ישירות לפעולה.

00:02:25.840 --> 00:02:29.560
העיכוב הזה הוא המקום שבו כל כך הרבה הזדמנויות פשוט הולכות לאיבוד.

00:02:29.560 --> 00:02:34.220
קידום מחירות שמושק שלוש שעות מאוחר מדי אחרי ירידה במחירות מאבד מהדחיפות שלו.

00:02:34.380 --> 00:02:38.300
זינוק בשגיאות באתר שנשאר ללא מענה עד לישיבת הסקירה הבאה,

00:02:38.560 --> 00:02:41.060
עולה לנו בהמרות שלעולם לא נקבל בחזרה.

00:02:41.220 --> 00:02:45.860
הפער בין הידיעה לבין הפעולה הוא בדיוק המקום שבו Fabric Data Activator פועל,

00:02:46.100 --> 00:02:48.100
והוא תוכנן לצמצם את הפער הזה לשניות.

00:02:48.320 --> 00:02:51.500
מכיוון שהוא מוטמע באופן טבעי בתוך Microsoft Fabric,

00:02:51.760 --> 00:02:56.640
אין צורך לייצא, לחבר או ללהטת ללא הרף בין מקורות נתונים עבור Data Activator.

00:02:56.640 --> 00:03:01.860
הוא קורא זרמי אירועים בזמן אמת ומגיב באופן מיידי כאשר תנאי שהגדרת מתקיים.

00:03:02.120 --> 00:03:07.660
ההבדל הוא שבמקום לעצור בהתראה בלבד, הוא יכול להפעיל תגובת שרשרת בשאר המערכות שלך.

00:03:07.840 --> 00:03:11.600
דמיין זאת, עדכון מחירות חי מנטר ביצועים באזורים שונים.

00:03:12.200 --> 00:03:16.440
בדרך כלל, תבחין בירידה פתאומית באזור מסוים בלוח המכוונים שלך,

00:03:16.600 --> 00:03:20.900
תחקור, תנסה החצאה ממוקדת, תקבל אישור ותעלה את המבצע לאוויר.

00:03:20.900 --> 00:03:29.280
זה עשוי לקחת שעה. עם Data Activator, אותה ירידה יכולה להפעיל קריאת API מאושרת מראש למערכת האוטומציה השיווקית שלך,

00:03:29.600 --> 00:03:33.900
ולהשיק הצעה ממוקדת תוך דקות לפני שהמתחרים בכלל יראו חולשה.

00:03:34.100 --> 00:03:38.900
אין צורך לחכות שהאדם הנכון יבחין בכך, ואין עיכוב בדיונים על מהלך מובן מאליו.

00:03:39.120 --> 00:03:40.300
זהו השינוי האמיתי.

00:03:40.480 --> 00:03:44.220
כלי ביי מסורתיים עוקבים, Data Activator מאזין ומגיב.

00:03:44.220 --> 00:03:52.720
עם קצב ריינון טיפוסי של Power Buy, נניח כל 30 דקות, הזיהוי עצמו עלול להיות בפיגור כבר מרגע תחילת השינוי.

00:03:53.340 --> 00:04:00.420
טריגרים של Data Activator יכולים לפעול על זרמי אירועים בזמן אמת כמעט, בסדר גודל של שניות בהתאם למקור,

00:04:00.740 --> 00:04:04.720
מה שגורם לרגע הפעולה להתיישב הרבה יותר טוב עם אירוע הטריגר עצמו.

00:04:04.860 --> 00:04:09.420
ומכיוון שהוא שזור בתוך פבריק, הוא לא מוגבל ללוח מכוונים או לקבוצת נתונים אחת.

00:04:09.420 --> 00:04:12.600
הוא יכול להתחבר לכל חלק בעקו סיסטם שבו זה הגיוני.

00:04:12.740 --> 00:04:17.700
אותו עדכון זורם יכול להיות חלק מצינור נתונים, Data Pipeline, של Synapse,

00:04:17.980 --> 00:04:22.320
שמזין לאחר מכן מודלים מרובים בהמשך הזרם ומודלים של בינה מלאכותי.

00:04:22.420 --> 00:04:26.740
אם קורה משהו חשוב, Data Activator לא רק לוחש ללוח המכוונים שלך,

00:04:26.880 --> 00:04:31.860
הוא שולח את האות למערכות שמסוגלות לתקן או לנצל את ההזדמנות באופן מיידי.

00:04:32.380 --> 00:04:34.340
זהו הגשר בין תצפית לביצוע.

00:04:34.340 --> 00:04:39.880
במקום למלא את הצ'אט של הצוות שלך בהודעות להידיעתך שהצוות יראה רק אחרי ארוחת הצהריים,

00:04:40.140 --> 00:04:42.400
הוא מבצע את השלב הבא בדיוק שם וברגע זה.

00:04:42.540 --> 00:04:47.300
הוא הופך כל אירוע רלוונטי להחלטה שכבר התקבלה לפעולה שכבר בוצעה.

00:04:47.660 --> 00:04:51.600
כשמשווים אותו לזרימת עבודה סטנדרטית של ביי, היתרון ברור.

00:04:51.780 --> 00:04:54.020
ניתור בלבד מספר לך את הסיפור.

00:04:54.220 --> 00:04:56.340
ניתור בתוספת תגובה משנה את התוצאה.

00:04:57.180 --> 00:05:02.820
ובנוף שבו חלונות הזדמנויות נסגרים מהר, ההבדל הזה הוא יותר מנוחות ותחרותיות.

00:05:03.620 --> 00:05:11.080
בהמשך נראה כיצד זה משתלב באופן טבעי בכלים שאתה כבר עובד בהם מבלי להוסיף שכבת מורכבות נוספת לניהול.

00:05:11.260 --> 00:05:13.660
יותר מסתם התראות, הרשת של פבריק.

00:05:13.800 --> 00:05:17.560
לשלוח לך עוד פינג, בטימס זו לא אוטומציה, זה רק עוד רעש.

00:05:17.560 --> 00:05:18.860
אתה יודע למה הכוונה.

00:05:19.040 --> 00:05:24.480
מבול של הודעות קופצות על כל מסך, כל אחת דורשת שתבדוק משהו שאולי חשוב ואולי לא.

00:05:24.700 --> 00:05:31.920
בהתחלה יש תחושה ששולטים בעניינים, אבל מהר מאוד הצוות מתחיל להתעלם מהן, והחשובות נעלמות בתוך הקאוס.

00:05:32.740 --> 00:05:37.580
האירוניה היא שהמערכות שאמורות לעדכן אתכם בסוף גורמות לכם להיות עיוורים יותר.

00:05:37.800 --> 00:05:45.160
כולנו ישבנו בשיבת יום שני שבה מישהו מציין שהוא פספס בעיית לקוח גדולה רק כי ההתראה נראיתה כמו כל השאר.

00:05:45.160 --> 00:05:50.360
שורש הבעיה אינו חוסר בזיהוי, אלא חוסר בתבונה לגבי מה לעשות הלאה.

00:05:50.720 --> 00:05:57.740
התראות רגישות מדי מתייחסות לכל תנודה קטנה כאל משבר, וזה יוצר תרבות שבה כולם מאומנים להתעלם מהן.

00:05:58.460 --> 00:06:03.080
כאן הדטא אקטיבייטור של מייקרוסופט פאבריק מתחיל להפוך למשמעותי.

00:06:03.880 --> 00:06:09.900
הוא לא רק מחובר מבחוץ, הוא פועל לצד פאוור ביי, סינפס ומערכות ניהול הנתונים של פאבריק.

00:06:09.900 --> 00:06:15.360
זה אומר שהוא פועל באותו מגרש משחקים כמו הכלים שכבר מריצים את הניתוחים והצינורות שלכם.

00:06:15.480 --> 00:06:20.820
במקום לשלוח לכם פינג בכל פעם שמדד משתנה, הוא יכול להחליט אם השינוי מצדיק את עצירת התהליך.

00:06:20.960 --> 00:06:26.640
תחשבו עליו כעל מרכזנית מהדור הישן, אבל כזו שמבינה באמת את הדחיפות מאחורי כל שיחה.

00:06:26.760 --> 00:06:32.080
כשמה שהוא קורא, למשל עדכון נתונים שולח איתות שפורמת שמות המוצר השתבש באמצע הטעינה.

00:06:32.080 --> 00:06:35.520
Data Activator יודע אילו חוטים מתחברים למערכות הנכונות.

00:06:35.700 --> 00:06:38.780
הוא לא שולח לצוות השיווק התראה שהם יקראו רק מחר.

00:06:38.940 --> 00:06:45.180
הוא מנתב את הבעיה ישירות למערכת שיכולה לעצור את הטעינה הפגומה לפני שהיא מרעילה דוחות במורד הזרם.

00:06:45.360 --> 00:06:46.480
הנה דוגמה מעשית.

00:06:46.640 --> 00:06:50.900
צינור נתונים של סינפס שואב נתוני עסקאות פיננסיות בכל כמה שניות.

00:06:51.140 --> 00:06:55.820
אחת המערכות במעלה הזרם מתחילה לשלוח רשומות כפולות בגלל תקלה אצל הספה.

00:06:55.820 --> 00:07:01.280
אם אתם משתמשים רק בהתראות, אתם תראו הודעת טימס או אימייל שאומר, שלום, זוהו רשומות כפולות.

00:07:01.440 --> 00:07:03.620
אז עכשיו זה ברשימת המטלות של מישהו.

00:07:03.780 --> 00:07:08.140
עם Data Activator בתמונה, הוא יכול לעצור את הצינור ברגע שהכפילויות מגיעות,

00:07:08.380 --> 00:07:13.540
מה שנותן למאנדסי הנתונים זמן לתקן את המקור לפני שהמידע השגוי מגיע למחסן הנתונים.

00:07:13.740 --> 00:07:18.040
התיקון קורה ברמת המערכת, לא בגלל שמישהו במקרה בדק את לוח המכוונים.

00:07:18.300 --> 00:07:19.220
זה הבדל קריטי.

00:07:19.220 --> 00:07:23.020
Data Activator אינו קשור לסט נתונים בודד או לזרם צר.

00:07:23.020 --> 00:07:29.880
הוא עובד עם סוגי כלת מרובים, טבלאות מחסן נתונים, זרמי אירועים ומקורות נתונים אחרים של פבריק,

00:07:30.160 --> 00:07:33.300
ומכיל חוקים לוגיים מבלי שתצטרכו להשגיח עליהם.

00:07:33.440 --> 00:07:37.340
היקף הפעילות הבין שירותי הזה אומר שהוא לא רק יודע כשמשהו לא קשורה.

00:07:37.500 --> 00:07:40.560
הוא יודע בדיוק מתי ללחוץ על הבלמים ומתי לתת גז.

00:07:40.700 --> 00:07:45.780
ומכיוון שהוא חי בתוך אותה מערכת אקולוגית שבה נמצאים לוגיקת הטרנספורמציה והיחסון שלך,

00:07:45.780 --> 00:07:47.420
הוא לא נאבק בזרימות הנתונים.

00:07:47.420 --> 00:07:53.960
הוא מוטמע בתוכן, לכן ניתן להגדיר שרשרת שבה קליטה, טרנספורמציה, תיקוף ופתרון קורים ברצף אחד,

00:07:54.240 --> 00:07:57.260
בלי שאנשים יצטרכו לרדוף זה אחרי זה למסירת משימות.

00:07:57.380 --> 00:08:04.720
זה ההבדל בין להגיב לנתונים לבין העובדה שהמערכות שלך מסתגלות תוך כדי תנועה כדי לשמור על איכות ועמידה בזמנים.

00:08:04.900 --> 00:08:11.360
אבל, התועלת האמיתית מתחילה להתגלות כשלא רואים בזה כלי התראות, אלא שכבת קבלת החלטות תפעולית.

00:08:11.360 --> 00:08:20.000
זה מגיב בהתבסס על הקשר, מה שמפחיד דרמטית את כמות הרעש ומגדיל את אחוז ההתראות שבאמת מובילות לפעולה משמעותית.

00:08:20.840 --> 00:08:26.280
אתה כבר לא מוצף. אתה מקבל אותות על פני רעש עם פחות עבודה ידנית.

00:08:26.780 --> 00:08:33.500
ומכיוון שההחלטות אלו יכולות לעורר שינויים של ממש, כמו השיית עבודות, עדכון רשומות או התחלת תהליכי תיקון,

00:08:33.500 --> 00:08:37.940
זה לא רק מצמצם את העיכוב בין הידיעה לעשייה, זה מוחק את הפער לחלוטין.

00:08:38.080 --> 00:08:43.580
עכשיו, בואו ניגש לחלק שתופס את העין, קריאת ממשקי API והתממשקות עם העולם שמחוץ למייקרוסופט.

00:08:43.680 --> 00:08:49.280
כי שמה שבפנים קורה לעולם שבחוץ, הנתונים שלך יכולים לבצע שיחת טלפון עוד לפני שתראה את השיחה שלא נהנתה.

00:08:49.380 --> 00:08:54.100
זו לא מתאפורה. אנחנו מדברים על לקחת את אותו זרם אירועים שאתה כבר רוקב אחריו,

00:08:54.100 --> 00:08:58.260
ולתת לו להפעיל משהו מחוץ למערכת המיקרוסופט פבריק בזמן אמת.

00:08:59.020 --> 00:09:02.860
במקום לחכות שתקרא לוח מכוונים או תלחץ על התראת טימס,

00:09:03.120 --> 00:09:06.820
המערכת עצמה מחייגת החוצה, באופן מטאפורי או מילולי,

00:09:07.140 --> 00:09:11.060
כדי להפעיל פעולה באפליקציה או שירות אחר ברגע שהתנאי מתקיים.

00:09:11.300 --> 00:09:13.940
רוב מערכות הבי נכשלות בדיוק כאן.

00:09:14.080 --> 00:09:19.380
הן מצוינות בהצפת תובנות, לפעמים אפילו עם ויזואליזציה מרשימה ופרשנות מבוססת בינה מלאכותית,

00:09:19.380 --> 00:09:22.080
אבל הן מוסרות לך את הכדור ומצפות שתרוץ איתו.

00:09:22.180 --> 00:09:25.400
אתה עדיין צריך לפתוח את ה-CRM, לשלוח את ההזמנה,

00:09:25.640 --> 00:09:28.160
להדכן את ה-ERP או להפעיל את התהליך ידני.

00:09:28.280 --> 00:09:31.600
הפער הזה הוא המקום שבו צבר הבקבוק האנושי חוזר פנימה.

00:09:31.720 --> 00:09:33.740
אתה אולי מזהה את הבעיה תוך דקות,

00:09:33.960 --> 00:09:37.960
אבל הביצוע קורה שעות לאחר מכן כי מחכים שמישהו יהיה פנוי לפעול.

00:09:38.100 --> 00:09:41.940
עם Data Activator, השלב הזה לא רק מתקצר, הוא פשוט נעלם.

00:09:41.940 --> 00:09:46.760
דמיין שרמות המלאי יורדות מתחת לסף ההזמנה מחדש שלך באמצע היום.

00:09:47.380 --> 00:09:51.000
במערך רגיל, מישהו בתפעול מבחין בזה בפאור ביי,

00:09:51.320 --> 00:09:53.520
שולח הודעה לרכש ומחכה לאישור.

00:09:53.740 --> 00:09:57.540
בינתיים, אתה ממשיך למכור את המוצר ומתקרב לחוסר במלאי.

00:09:57.680 --> 00:10:02.780
במקום זאת, Data Activator יכול לשלוח קריאת API ישירות למערכת ההזמנות של הספק

00:10:02.780 --> 00:10:04.920
שלך ברגע שהנתונים חוצים את הקו הזה.

00:10:05.120 --> 00:10:07.260
הזמנת רכש נכנסת, משלוח בתור,

00:10:07.260 --> 00:10:11.240
אף אחד בצוות שלך עוד לא קרה את ההתראה, והתיקון כבר בתנועה.

00:10:11.360 --> 00:10:14.660
זה הערך של ביצוע קריאות חיצוניות ישירות מתוך פאבריק.

00:10:14.820 --> 00:10:16.500
אתה לא מוגבל לכלי מייקרוסופט,

00:10:16.700 --> 00:10:19.820
בין אם מדובר בסיאס CRM, מערכת ERP ישנה,

00:10:20.120 --> 00:10:23.360
נקודת קצה רסט מותאמת אישית או אפילו API של שותף,

00:10:23.600 --> 00:10:27.540
אתה יכול לחבר את הטריגר בזמן אמת כדי לגשר על הפער בין זיהוי לפתרון.

00:10:28.720 --> 00:10:31.860
הפלט יכול להיות פשוט כמו שליחת נתונים לוואו,

00:10:31.860 --> 00:10:37.640
או מובנה כמו שליחת מטען מפורמט שמפעיל תהליך עבודה רב של בי בפלטפורמה אחרת לגמרי.

00:10:39.300 --> 00:10:43.400
זו הנקודה שבה פאבריק מפסיקה להיות רק אוסף של כלי ניתוח,

00:10:43.580 --> 00:10:48.020
ומתחילה לתפקד כמו מערכת העצבים המרכזית של הסביבה התפעולית שלך.

00:10:48.640 --> 00:10:49.980
כאשר מתרחש אירוע,

00:10:50.260 --> 00:10:52.140
העצב לא רק שולחות לעיניים,

00:10:52.360 --> 00:10:55.500
הוא דוחף הנחיות לעברים שיכולים לפעול באופן מיידי.

00:10:55.720 --> 00:11:00.140
כך אתה עובר מניתור פעולות למצב שבו הן מבסטות את עצמן במידה רבה.

00:11:00.140 --> 00:11:03.140
אתה יכול לראות זאת בתעשיות עם נוכחות IOT משמעותית.

00:11:03.860 --> 00:11:08.220
תאר לעצמך מפעל ייצור עם חיישני רטט המותקנים על מכונות קריטיות.

00:11:08.460 --> 00:11:11.380
חיישנים אלו מזרימים נתונים לפאבריק בזמן אמת.

00:11:11.600 --> 00:11:14.000
ברגע שקריאה חורגת לטווח הזהרת קשל,

00:11:14.220 --> 00:11:18.480
Data Activator יכול לבנות ולהקצות הוראת עבודה ב-Dynamics 365

00:11:18.480 --> 00:11:22.180
ולתזמן מהנדס עוד לפני שהמכונה מתקרבת לחשל.

00:11:22.380 --> 00:11:25.980
אף מנהל לא צריך להפסיק את יום העבודה שלו כדי לבצע את השיחה,

00:11:25.980 --> 00:11:30.060
המערכת מנתבת את המשימה אוטומטית עם כל ההקשר שהטכנאי צריך.

00:11:30.180 --> 00:11:34.020
עבודת התיקון מתחילה עוד לפני שזמן השבטה הופך בכלל לנושא לשיחה.

00:11:34.140 --> 00:11:38.900
השילוב של ניתור אוטומטי ואפיס יוצאים הוא המקום שבו האוטונומיה האמיתית נכנסת לפעולה.

00:11:39.020 --> 00:11:41.100
אתה לא רק מסנן התראות לפי רלוונטיות,

00:11:41.320 --> 00:11:44.840
אתה מחבר את אותם טריגרים מסוננים לפעולות מוחשיות שמתרחשות מיד.

00:11:44.840 --> 00:11:48.640
זהו זינוק מלהיות מונע מנתונים ללהיות מופעל על ידי נתונים,

00:11:48.960 --> 00:11:52.260
שבו יכולת התגובה של המערכת מהירה כיכולת הזיהוי שלה.

00:11:52.440 --> 00:11:57.140
כשמגדירים את זה נכון, התהליכים שלך לא רק מבטרים על ניהול מיקרו-אנושי,

00:11:57.420 --> 00:12:02.320
הם משתפרים באופן פעיל כי הלולאה בין זיהוי לפעולה היא הדוקה, עקבית ותמידית.

00:12:02.960 --> 00:12:08.340
אתה יכול להתמקד בתכנון חוקים ולוגיקה טובים יותר במקום לדאוג עם מי שהוא ראה את ההתראה.

00:12:08.340 --> 00:12:12.560
אבל אפילו למערכת העצבים המגיבה ביותר יש ספים שאי אפשר להתעלם מהם,

00:12:12.680 --> 00:12:16.880
ואם לא תכיר אותם לפני שתתחיל, התוצאות עלולות להפוך למבולגנות מהר מאוד.

00:12:17.480 --> 00:12:24.580
ידיעת הגבולות לפני הבנייה, לכל גיבור אוטומציה יש סיפור רקע ורשימה של מכשולים שהוא היה רוצה לצפות מראש.

00:12:25.380 --> 00:12:30.800
עם Data Activator, המציאות היא שבעוד שהרעיון של זיהוי פלוס תגובה נשמע בלתי מוגבל,

00:12:30.800 --> 00:12:33.300
יש מסגרת עבודה מאוד מעשית מתחתיו.

00:12:33.520 --> 00:12:36.920
זה לא קסם, זה עדיין רץ על הארכיטקטורה של פבריק,

00:12:36.920 --> 00:12:43.500
כפוף לאותם מודלים של קיבולת, מגבלות שירות והנחות תכנון שחלים על כל דבר אחר בעקוס סיסטם.

00:12:43.760 --> 00:12:50.020
אם תתעלמו מהגבולות האלה, תגלו מהר מאוד מה קורה כשמערכת אוטומציה בעלת כוונות טובות פשוט נעצרת.

00:12:50.220 --> 00:12:54.900
החלק המתאה הוא שנקודות החשל בדרך כלל לא מופיעות במהלך הוכחת ההיתכנות שלכם.

00:12:55.080 --> 00:12:57.080
בבדיקה קטנה, הכל מרגיש מיידי.

00:12:57.080 --> 00:13:01.020
תנאים מופעלים, פעולות יוצאות לפועל, ואתם רואים את התוצאה כמעט מיד.

00:13:01.020 --> 00:13:09.000
רק כשמרחיבים את הפעילות, מחברים מערכות חיצוניות מרובות, מגדילים את נפח הטריגרים ומוסיפים לוגיקה מורכבת, המגבלות מתחילות לתת את אוטותיהן.

00:13:09.120 --> 00:13:11.800
השעיה מצטברת, השימוש בקיבולת מזנק.

00:13:11.960 --> 00:13:16.940
לפתע, מנוע קבלת ההחלטות בזמן אמת נתקל בהגבלות או נכנס לתור המתנה.

00:13:17.200 --> 00:13:24.000
חשבו מה קורה כשטרגר תלוי במקור שמחובר טכנית, אך אינו פועל בתוך השירותים המובנים של פבריק.

00:13:24.000 --> 00:13:29.640
אולי יש לכם זרם נתונים המגיע ממרכז אירועים חיצוני שמזין את הדוחות שלכם.

00:13:29.900 --> 00:13:38.280
אם Data Activator מסתמך על הזרם הזה כדי להפעיל תהליך קריטי, אך מרווח העיבוד בצד המקור איתי מזמן התגובה של פבריק,

00:13:38.580 --> 00:13:40.960
לעולם לא תקבלו את המהירות שאתם מצפים לה.

00:13:40.960 --> 00:13:47.180
ראיתי התמאות שנתקעו כי התנאים התבססו על נתונים סטטיים למחצה שלא יכלו לעמוד בקצב של לוגיקת הטריגר.

00:13:47.300 --> 00:13:50.760
האוטומציה לא נכשלה, היא פשוט הגיעה מאוחר מדי מכדי להיות רלוונטית.

00:13:50.760 --> 00:13:54.660
קיימת גם הפיתוי לנטר הכל. עכשיו זה נשמע הגיוני בהתחלה.

00:13:54.860 --> 00:13:58.280
יותר תנאי ניתור אמורים להוביל ליותר הזדמנויות להגיב,

00:13:58.600 --> 00:14:03.320
אך כל טריגר שתגדירו תורם לאומס העבודה שרץ מול קיבולת הפבריק שלכם.

00:14:03.320 --> 00:14:10.020
זה אומר שאתם מנצלים את אותה קיבולת שתומכת ברענוני הבי בזרימות הנתונים ובישאילתות ה-Worry House שלכם.

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

00:14:16.900 --> 00:14:22.620
תכנון קיבולת אינו אופציונלי כאן, שכן זו המשמעת שמונעת מהאוטומציה להפוך להשבטה שנגרמה במו ידיכם.

00:14:22.780 --> 00:14:24.460
גם ליעדי השאיה יש חשיבות.

00:14:24.640 --> 00:14:30.080
Data Activator יכול להגיב בשניות, אך רק עם המערכות במעלה ובמורד הזרם מסוגלות לעמוד במהירות הזו.

00:14:30.080 --> 00:14:38.080
אם קריאת ה-API המופעלת שלכם מצביעה על אינטגרציית ERP שעוברת עיבוד הצוות כל 15 דקות, יצרתם לעצמכם עיכובים מובנים מראש.

00:14:38.080 --> 00:14:41.860
הטריגר מופעל, אך התוצאה הסופית עדיין מחכה לעצבה הבאה.

00:14:41.980 --> 00:14:46.740
יש למפות את ההבדלים האלה בקצב השירות לפני שמתחילים לחבר מערכות זו לזו.

00:14:46.880 --> 00:14:51.120
הדרך הבטוחה יותר היא להתחיל עם תנאים בעלי ערך גבוה ותדירות נמוכה.

00:14:51.120 --> 00:14:58.240
זה אומר לבחור תרחישים שבהם גם אם אתם מפעילים אותם רק כמה פעמים ביום, לכל אחד יש השפעה ברורה שמצדיקה אוטומציה.

00:14:58.400 --> 00:15:03.680
המטרה היא להוכיח יעילות מבלי להציף את הקיבולת שלכם או להעמיס על שירותי המורד.

00:15:03.680 --> 00:15:09.280
אתם מכוונים את לוגיקת הטריגר, מבינים את פרופיל העיבוד, ורק אז מתחילים להתרחב.

00:15:09.900 --> 00:15:14.240
כדאי גם לזכור שתמכור וקיבולת אינם עוסקים רק בהכסון או בריינונים.

00:15:14.240 --> 00:15:18.440
הערכת טריגרים וביצוע פעולות צורכים משאבים מאותה בריכה משותפת.

00:15:18.540 --> 00:15:21.300
קריאת ה-API היוצאת הזו זה כוח עיבוד.

00:15:21.500 --> 00:15:24.840
הטרנספורמציה שאתם מריצים לפני בדיקת תנאי גם מחשבת.

00:15:24.840 --> 00:15:29.540
אם תרחיבו תנאים וחיבורים מבלי להביא בחשבון את המאגר בחידות הפבריק שלכם,

00:15:29.800 --> 00:15:32.000
תגיעו לתקרות מהר יותר ממה שאתם מצפים.

00:15:32.220 --> 00:15:36.240
החדשות הטובות הן שברגע שאתם יודעים איפה המגבלות, אתם יכולים לתכנן בהתאם.

00:15:36.240 --> 00:15:38.260
אתם בונים תהליכים שבאופן עצמאי.