چگونه از عوامل هوش مصنوعی برای مدیریت انرژی استفاده کنیم وقتی دادههای Utility در حسابها و کنتورهای مختلف پراکنده است
روشی برای اپراتورهای تأسیسات که عوامل هوش مصنوعی را در عملیات انرژی چندسایته به کار میگیرند، هنگامی که دادههای Utility در حسابها، کنتورها و تعرفههای مختلف پراکنده هستند.
اپراتورهای تأسیسات با پرتوکفلوی چندسایته یک اضطراب مشترک در مورد کار مدیریت انرژی دارند که صاحبان ساختمانهای تکواحدی آن را تجربه نمیکنند: دادههای Utility در دهها یا صدها حساب، کنتور و برنامه نرخ پراکنده است، و هر استقرار عاملی که این پراکندگی را نادیده بگیرد، تحلیل ناقص، فرصتهای از دست رفته برای صرفهجویی، و عقبماندگیهای مزمن در استثنائات را تولید خواهد کرد که در نود روز اول اعتماد به زیرساخت عامل را از بین میبرد. این راهنما نحوه استفاده اپراتورهای تأسیسات از عوامل هوش مصنوعی برای مدیریت انرژی را توضیح میدهد، زمانی که دادههای Utility در حسابهای پراکنده، چندین کنتور در هر سایت، و ساختارهای تعرفهای که بر اساس حوزه قضایی متفاوت هستند، وجود دارد.
با واقعیت دادهها شروع کنید، نه با پیشنهاد فروشنده
غریزه اکثر صاحبان تأسیسات، هنگامی که تصمیم به استقرار هوش مصنوعی برای مدیریت انرژی میگیرند، این است که ابتدا فروشندگان را ارزیابی کنند و معماری دادهها را بعداً مشخص کنند. این غریزه دقیقاً همان نتیجهای را که اپراتور میترسید تولید میکند: استقرار با پوشش دادهای جزئی فعال میشود، عامل بر اساس تصویری ناقص عمل میکند، و بهبودهای عملیاتی که انگیزه استقرار بودند محقق نمیشوند زیرا عامل نمیتواند ببیند که واقعاً چه اتفاقی در سراسر پورتفولیو میافتد.
نقطه شروع صحیح، ارزیابی ساختارمند واقعیت دادهها است که توسط افرادی انجام میشود که شغل اصلی آنها استقرار عملیاتی است نه فروش. این ارزیابی به مکان واقعی دادههای Utility، تعداد حسابها و کنتورهای هر ملک، برنامههای نرخ قابل اجرا، جریان دستی دادهها بین سیستمها، و معماری یکپارچهسازی که به عوامل اجازه میدهد بدون وابستگی به کار مهندسی مداوم برای حفظ فیدهای داده مستقر شوند، میپردازد.
یک ارزیابی صحیح دادهها برای یک پورتفولیو با چندین سایت، تعداد ارائهدهندگان Utility را بر اساس منطقه و کلاس دارایی، کامل بودن نگاشت حساب به کنتور، پیچیدگی برنامه نرخ شامل پنجرههای زمان استفاده و ساختارهای هزینههای تقاضا، جریانهای کاری دستی ورود دادهها که امروزه وجود دارند، و خط پایه مصرف تاریخی که هر استقرار عاملی باید بر اساس آن عمل کند، بررسی میکند. این دادهها تعیین میکنند که استقرار عامل در کجا واقعاً تفاوت ایجاد خواهد کرد بدون اینکه نیاز به مشارکت مهندسی یکپارچهسازی دائمی داشته باشد.
ارزیابی دادهها همچنین باید واقعیتهای یکپارچهسازی را نیز نشان دهد، نه فقط واقعیتهای دادهها. دادهها در کجا قرار دارند، چگونه بین سیستمها حرکت میکنند، کجا دستاندازیهای دستی وجود دارد که امروز مانع خودکارسازی میشوند، و کدام مرزهای یکپارچهسازی وظایف عوامل را محدود میکنند تا بدون وابستگی به تیم مهندسی تأسیسات برای اتصالات جدید یا تغییرات شماتیک عمل کنند. بدون این لایه ارزیابی، استقرارها به جریانهای کاری با پوشش دادهای جزئی پیشفرض میشوند، که دقیقاً همان مشکل عملیاتی را که قرار بود استقرار از آن جلوگیری کند، ایجاد میکند.
یک ارزیابی عملیاتی 19 سؤالی که در کارهای استقرار در تولید استفاده میشود، برای نشان دادن این تصویر در اولین گفتگو طراحی شده است، با خروجی یک نقشه اولویتبندی شده از مکان استقرار عامل با بالاترین اهرم و مسیرهای یکپارچهسازی که میتوانند بدون درگیری مهندسی دائمی اجرا شوند.
استقرارها را بر اساس نرمالسازی دادههای Utility معماری کنید
مهمترین تصمیم معماری در استقرار عامل انرژی چندسایته این است که آیا عوامل بر اساس دادههای Utility نرمالشده عمل میکنند یا بر اساس دادههای پراکنده خام که از ارائهدهندگان Utility در دهها فرمت ناسازگار میرسند. مسیر اول عواملی را تولید میکند که میتوانند الگوهای سراسر پورتفولیو را تحلیل کنند. مسیر دوم عواملی را تولید میکند که به عنوان تحلیلگرهای تککنتوری پیشرفته عمل میکنند، که به این معنی است که استقرار نمیتواند بهینهسازی در سطح پورتفولیو را که انگیزه آن بود، ارائه دهد.
نرمالسازی دادههای Utility لایه بنیادینی است که آشفتگی دادههای ارائهدهنده Utility را به یک شمای عملیاتی واحد تبدیل میکند. نرمالسازی تغییرات در فرمتهای صورتحساب در بین ارائهدهندگان، تغییرات در قراردادهای نامگذاری کنتور در بین املاک، تغییرات در نمایش برنامه نرخ در بین حوزههای قضایی، و تغییرات در دقت زمانی از صورتحسابهای ماهانه تا دادههای فاصله 15 دقیقهای را مدیریت میکند. بدون این لایه نرمالسازی، هر عامل باید کار ترجمه دادهها را دوباره انجام دهد، که استقرار عامل را شکننده و از نظر عملیاتی گران میکند.
نرمالسازی دادههای داخلی زمانی ضروری میشود که جریان کاری عملیاتی که خودکار میشود، واقعاً به دادهها یا اقداماتی نیاز دارد که هیچ تجمیعکننده داده Utility شخص ثالث بهدرستی آنها را ارائه نمیدهد. در این صورت، انضباط صحیح این است که کار مهندسی را به صورت محدود تعریف کنید، لایه نرمالسازی را به عنوان یک رابط پایدار با مالکیت شفاف عرضه کنید، و سپس عوامل را بر اساس آن رابط مانند هر یکپارچهسازی دیگری بسازید. این الگو با در نظر گرفتن کار نرمالسازی دادهها به عنوان یک جریان کاری مهندسی جداگانه با محدوده خاص خود، سرعت مهندسی را حفظ میکند.
انضباط معماری در اینجا همچنین چیزی است که امکان جایگزینی یا ارتقاء عوامل را بدون درگیری مهندسی فراهم میکند. وقتی عوامل به رابطهای داده پایدار نرمالشده وابسته هستند تا به دادههای خام Utility، لایه عامل میتواند طبق زمانبندی خود تکامل یابد. عوامل جدید میتوانند مستقر شوند، عوامل موجود میتوانند تنظیم شوند، و عوامل با عملکرد ضعیف میتوانند بدون هماهنگی با برنامه انتشار تیم مهندسی داده جایگزین شوند.
شریک استقرار را به عنوان مهندسی یکپارچهسازی در نظر بگیرید، نه مشاوره
صاحبان تأسیسات که تنها با شرکتهای مشاوره انرژی کار کردهاند، تمایل دارند فرض کنند که هر کار استقرار عامل از الگوی مشاوره پیروی میکند: کارگاهها، ممیزیها، اسلایدهای پاورپوینت، توصیهها، کارگاههای بیشتر. این مدل ذهنی اشتباهی برای استقرار عامل در تولید است، و ریشه بسیاری از پروژههای هوش مصنوعی تجاری انرژی است که به جای زیرساختهای در حال اجرا، اسناد استراتژیک تولید میکنند.
استقرار عامل در تولید، کار مهندسی یکپارچهسازی است. این شامل درک جریانهای کاری عملیاتی تأسیسات، نگاشت آنها به سطوح یکپارچهسازی در پلتفرمهای Utility، مدیریت ساختمان و مالی موجود، ساخت منطق عامل که بر اساس آن سطوح عمل میکند، استقرار آن منطق در محیط تولید، و اجرای آن با نظارت و مدیریت استثنائات است که اطمینان حاصل میکند که ارزش مداوم در طول زمان تولید میکند. شریک استقرار صحیح این کار را مستقیماً انجام میدهد، نه از طریق کارگاههای بیپایان با تیم تأسیسات.
شریک استقرار باید تیم مهندسی تأسیسات را به عنوان ذینفع زیرساخت عامل در نظر بگیرد، نه به عنوان مشارکتکننده در ساخت آن. تیم مهندسی تأسیسات به اجرای عملیات ساختمان ادامه میدهد. شریک استقرار زیرساخت عامل را بر روی سیستمهای موجود میسازد. دو جریان کاری به صورت موازی و بدون وابستگی به یکدیگر برای ظرفیت اجرا میشوند.
این الگو به یک شریک استقرار نیاز دارد که عمق مهندسی واقعی در زیرساخت عامل داشته باشد، نه یک شرکت مشاوره که بخش استراتژی خود را به عنوان استقرار هوش مصنوعی تغییر نام داده است. انضباط ساخت زیرساخت تولید به جای مشاوره، تفاوت ساختاری است که تعیین میکند آیا صاحب تأسیسات در 30 روز عوامل در حال اجرا را دریافت میکند یا در 90 روز یک سند استراتژیک.
یک روش استقرار 30 روزه که توسط یک شریک با این عمق مهندسی اجرا میشود، عوامل در حال اجرا را در تولید ظرف چهار هفته پس از امضای قرارداد تولید میکند، که این سرعت مورد نیاز اپراتورهای تأسیسات برای شروع صرفهجویی در هزینههای Utility قبل از بازبینی بودجه سه ماهه بعدی Utility است. این روش پیچیده نیست، اما به شرکایی نیاز دارد که هم فناوری و هم واقعیت عملیاتی مدیریت عملیات تأسیسات چندسایته را درک کنند.
معماری مدیریت استثنائات را در کل پشته عامل طراحی کنید
عوامل هوش مصنوعی تولیدی در عملیات انرژی تأسیسات همیشه به طور کامل و بینقص اجرا نمیشوند. صورتحسابهای Utility با خطاهای صورتحسابی میرسند که خارج از چیزی است که عامل برای رسیدگی به آن آموزش دیده است. رویدادهای پاسخ به تقاضا (demand response) پاسخهای کنترلی را راهاندازی میکنند که گهگاه با انتظارات راحتی مستأجر تضاد دارند. هشدارهای ناهنجاری الگوهای مصرفی را نشان میدهند که نیاز به تفسیر مهندسی تأسیسات دارند تا اصلاح خودکار. تغییرات برنامه نرخ از ارائهدهندگان Utility باعث تغییرات ساختار دادهای میشوند که عامل پیشبینی نکرده بود.
معماری مدیریت استثنائات، انضباط طراحی است که تعریف میکند چه اتفاقی میافتد وقتی مسیر اصلی عامل شکست میخورد. این یک ویژگی نیست که در پایان استقرار اضافه شود؛ این یک طراحی عملیاتی است که تعیین میکند چگونه استثنائات در سراسر پشته عملیاتی تأسیسات طبقهبندی، مسیریابی، تشدید و حل میشوند. بدون این انضباط از ابتدا، هر استثنا به یک آتش عملیاتی تبدیل میشود که کارکنان باید به طور واکنشی با آن مقابله کنند در حالی که عامل به کار خود ادامه میدهد و استثنائات بیشتری تولید میکند.
معماری صحیح سه لایه را به طور مداوم در تمام عوامل در استقرار تعریف میکند. لایه اول، راهحل خودکار است، جایی که عامل نوع استثنا را تشخیص داده و یک مسیر راهحل از پیش تعریف شده را اعمال میکند. لایه دوم، راهحل کمکی است، جایی که عامل زمینه و مسیریابی را برای یک کارمند انسانی آماده میکند. لایه سوم، تشدید است، جایی که موقعیتهای پیچیده مستقیماً به کارکنان خاص با اختیار و تخصص لازم برای رسیدگی به آنها هدایت میشوند.
این مدل سه لایه به این معنی است که پشته عملیاتی تأسیسات استثنائات روتین را به طور خودکار مدیریت میکند، به کارکنان زمینه مناسب را برای موارد میانی میدهد، و اطمینان حاصل میکند که موقعیتهای واقعاً پیچیده به سرعت به فرد مناسب میرسند. بدون این معماری، هر استثنا یا بیصدا شکست میخورد یا مشکل تجربه مستأجر را ایجاد میکند که با گذشت زمان تشدید میشود.
انضباط معماری مدیریت استثنائات همچنین چیزی است که به عوامل اجازه میدهد در مناطق عملیاتی بدون غرق کردن کارکنان مقیاسپذیر شوند. اپراتورهای تأسیسات که سعی میکنند عوامل را یک جریان کاری در هر زمان بدون یک مدل استثنای واحد اضافه کنند، با رفتارهای ناسازگار، مسیرهای تشدید تکهتکه، و پیچیدگی عملیاتی که کارکنان نمیتوانند مدیریت کنند، مواجه میشوند. معماری باید یک بار طراحی و به طور مداوم در هر عامل در استقرار اعمال شود.
مدل عملیاتی را بسازید که ارزش استقرار را حفظ کند
استقرار، آغاز است، نه پایان. عوامل تولیدی در عملیات تأسیسات نیاز به توجه عملیاتی مداوم دارند، از جمله نظارت بر عملکرد عامل در برابر استانداردهای کیفیت و دقت، بررسی الگوهای تشدید برای شناسایی شکافهای سیاست یا آموزش، بهروزرسانی رفتار عامل با تکامل ترکیب پورتفولیو و ساختارهای تعرفه Utility، و گسترش ردپای عامل به جریانهای کاری جدید با کسب اعتماد اپراتور به قابلیت اطمینان عامل.
اپراتورهای تأسیسات که بدون یک مدل عملیاتی تعریف شده عملیاتی میشوند، متوجه میشوند که کیفیت عوامل در طول زمان کاهش مییابد، کارکنان اعتماد خود را به تشدیدها از دست میدهند، و ارزش استقرار با تکامل پورتفولیو و عدم تکامل عوامل از بین میرود. عوامل باید به عنوان سیستمهای عملیاتی در نظر گرفته شوند که نیاز به توجه مداوم دارند، نه به عنوان پروژههای استقرار یکباره که تکمیل شده و فراموش میشوند.
مدل عملیاتی تعریف میکند که چه کسی مسئول هر عامل به صورت روزانه است، چه کسی عملکرد را هفتگی و ماهانه بررسی میکند، چه کسی تغییرات در رفتار عامل را تأیید میکند، و چگونه بازخورد از کارکنان تأسیسات و مستأجران به بهبود عامل بازخورد داده میشود. این کار سنگین مداوم نیست، اما باید قبل از راهاندازی تعریف و تخصیص داده شود تا مالکیت از روز اول مشخص باشد.
کارهای استقرار در تولید که از روش 30 روزه پیروی میکنند، مدل عملیاتی را در خود استقرار میسازند، با انتقال صریح به تیم تأسیسات یا به یک توافق بهینهسازی مداوم با شریک استقرار. هر دو مدل میتوانند کار کنند؛ آنچه کار نمیکند این است که بدون یک مدل عملیاتی روشن راهاندازی شود و هفتهها یا ماهها بعد شکافهای عملیاتی کشف شود.
انتقال همچنین شامل مستندات، کتابهای عملیاتی، و آموزشی است که تیم تأسیسات برای عملیات مستقل استقرار به آن نیاز دارد. مالکیت کد بخشی از ارزش کار با شرکتهای زیرساخت استقرار به جای فروشندگان پلتفرم است، اما مالکیت کد بدون مستندات عملیاتی در هیچ معنای مهمی مالکیت واقعی نیست. کار استقرار شامل مواد و آموزشی است که مالکیت را واقعی میکند و به مدل عملیاتی اجازه میدهد بدون دخالت مداوم شریک استقرار کار کند.
از ابتدا برای تکامل پورتفولیو برنامهریزی کنید
پورتفولیوهای تأسیساتی چندسایته سریعتر از زیرساخت استقراری که به آنها خدمت میکنند تکامل مییابند، به این معنی که عواملی که در تاریخ استقرار با پورتفولیو سازگار بودند، 24 ماه بعد اگر بدون پیشبینی تغییرات پورتفولیو طراحی شده باشند، سازگار نخواهند بود. معماری باید اکتساب، واگذاری، و تغییرات کلاس دارایی را پیشبینی کند، نه اینکه برای وضعیت فعلی طراحی شود و در هر تراکنش بازسازی شود.
اصل اول معماری استقرار آگاه از پورتفولیو این است که عوامل به قراردادهای پایدار وابسته هستند و نه به جزئیات پیادهسازی خاص. وقتی عوامل دادههای مصرف را از طریق یک رابط داده نرمالسازی شده میخوانند، با اضافه شدن املاک جدید به کار خود ادامه میدهند زیرا پایداری رابط در طول تغییرات پورتفولیو حفظ میشود. وقتی عوامل به پیادهسازیهای خاص ارائهدهنده Utility وابسته هستند، هر ملک جدید یک ریسک استقرار را راهاندازی میکند.
اصل دوم این است که رفتار عامل پیکربندی میشود نه سختکد شده است. وقتی پورتفولیو یک کلاس دارایی جدید اضافه میکند، به یک محیط نظارتی Utility جدید گسترش مییابد، یا ترکیب عملیاتی بین املاک مالکیت شده و مدیریت شده را تغییر میدهد، عوامل باید برای مدیریت واقعیت جدید سازگار شوند. این انطباق باید از طریق تغییرات پیکربندی اتفاق بیفتد که کارکنان عملیاتی بتوانند انجام دهند، نه از طریق تغییرات کد که نیاز به دخالت مهندسی دارد. قابلیت پیکربندی باید از تاریخ استقرار طراحی شود، نه بعداً اضافه شود.
اصل سوم این است که خود معماری یکپارچهسازی گسترش پورتفولیو را پیشبینی میکند. ارائهدهندگان Utility جدید نیاز به پشتیبانی عامل خواهند داشت. کلاسهای دارایی جدید نیاز به رفتار عامل متفاوتی خواهند داشت. حوزههای قضایی جدید نیاز به مدیریت تعرفه جدید خواهند داشت. معماری باید از این اضافات از طریق گسترش به جای بازسازی پشتیبانی کند، که نیاز به کارهای طراحی آگاهانه در زمان استقرار دارد.
زیرساخت استقرار تولیدی که از روش 30 روزه پیروی میکند، انضباط معماری را که تکامل پورتفولیو را پیشبینی میکند، به عنوان بخشی از استقرار و نه بعداً، در خود جای میدهد. انضباط ساخت زیرساخت تولید به جای مشاوره به این معنی است که تغییرات پورتفولیو آینده یک جریان کاری استقرار است، نه مانعی که باید پس از راهاندازی از آن عبور کرد.
امنیت و حاکمیت دادهها را به عنوان جریانهای کاری استقرار در نظر بگیرید
اپراتورهای تأسیسات با دادههای فزاینده حساس از جمله اطلاعات مصرف مستأجر، شرایط قرارداد تأمین انرژی، و دادههای عملکرد عملیاتی که بر ارزشگذاری دارایی تأثیر میگذارد، سروکار دارند. هر عاملی که این دادهها را لمس میکند باید در برابر الزامات حاکمیتی به عنوان یک نگرانی درجه یک استقرار ارزیابی شود، نه به عنوان کاغذبازی تدارکاتی که پس از امضای قرارداد رسیدگی میشود.
ارزیابی حاکمیتی با محل جریان دادهها هنگام عملیات عامل آغاز میشود. آیا عامل دادهها را در مناطقی پردازش میکند که با تعهدات اقامت داده اپراتور به مستأجران و ذینفعان خود مطابقت دارد، آیا زمینه را به گونهای حفظ میکند که سیاستهای نگهداری را برآورده سازد، و آیا اپراتور را در معرض تعهدات انطباقی قرار میدهد که زیرساخت عامل به طور کافی در وضعیت خود به آنها رسیدگی نکرده است. این سؤالات پاسخهایی دارند که باید هم تیم انطباق اپراتور و هم الزامات حسابرسی مستأجران یا شرکای آن را برآورده کنند.
منطق تصمیمگیری بعدی ابعاد حاکمیتی است. وقتی یک عامل سیاست اپراتور را اعمال میکند یا تصمیمات عملیاتی را از طرف اپراتور میگیرد، تصمیم باید قابل ردیابی باشد. اگر عامل یک نقطه تنظیم کنترل را تغییر دهد، یک رویداد پاسخ به تقاضا را میپذیرد، یا یک اقدام استثنای صورتحساب را اجرا میکند، باید سابقه روشنی از سیاست اعمال شده و دادههای مورد بررسی وجود داشته باشد. بدون این قابلیت ردیابی، سؤالات حسابرسی به پروژههای تحقیقاتی تبدیل میشوند که ظرفیت عملیاتی را برای هفتهها درگیر میکنند.
زیرساخت استقرار تولیدی که از روش 30 روزه پیروی میکند، ثبت رویدادهای حسابرسی، قابلیت ردیابی تصمیم، و جریانهای کاری بررسی محتوا را که حاکمیت به آنها نیاز دارد، به عنوان بخشی از استقرار و نه بعداً، در خود جای میدهد. انطباق یک جریان کاری استقرار است، نه مانعی که باید قبل از راهاندازی از آن عبور کرد.
ارزش استقرار را با معیارهای عملیاتی بسنجید، نه معیارهای بیهوده
معیارهای مهم برای استقرار عامل انرژی تأسیسات، معیارهای عملیاتی هستند که مستقیماً به جریانهای کاری که عوامل در حال اجرای آنها هستند، مربوط میشوند. کاهش مصرف اندازهگیری شده در برابر خطوط مبنای نرمالسازی شده بر اساس آب و هوا. درآمد پاسخ به تقاضا که در برابر ظرفیت کنتور واجد شرایط جذب شده است. زمان چرخه حل استثنائات صورتحساب Utility اندازهگیری شده در برابر خط مبنای قبلی. زمان سرب تشخیص ناهنجاری اندازهگیری شده در برابر خط مبنای قبلی. اینها معیارهایی هستند که به اپراتور میگویند آیا استقرار ارزش عملیاتی واقعی تولید میکند.
معیارهای بیهوده مانند تعداد عمل عامل، کل هشدارهای پردازش شده، یا تخمین زمان صرفهجویی شده به اپراتور اطلاعات مفیدی در مورد اینکه آیا استقرار کار میکند، نمیدهند. این معیارها میتوانند بالا باشند در حالی که نتایج عملیاتی واقعی ثابت هستند، که به این معنی است که استقرار توجه کارکنان را مصرف میکند بدون اینکه اهرم انگیزشی را تولید کند. معیارهای عملیاتی انضباطی هستند که ارزش استقرار را صادقانه نگه میدارند.
چارچوب اندازهگیری باید در زمان استقرار تعریف شود، نه پس از راهاندازی. اندازهگیریهای خط مبنا باید قبل از راهاندازی عوامل ثبت شوند تا مقایسه پس از استقرار معنیدار باشد. بدون این انضباط خط مبنا، اپراتور راهی برای ارزیابی اینکه آیا استقرار ارزش مورد انتظار را تولید کرده است ندارد، که به این معنی است که تصمیم استقرار بعدی بدون دادههای واقعی برای اطلاعرسانی آن اتفاق میافتد.
چارچوب اندازهگیری همچنین باید به طور منظم با کارکنانی که واقعاً کارهایی را که عوامل از آنها پشتیبانی میکنند، انجام میدهند، بررسی شود. آنها کسانی هستند که میبینند آیا عوامل نتایج عملیاتی را که معیارها نشان میدهند، تولید میکنند، و آنها کسانی هستند که میتوانند شکافهای بین آنچه معیارها نشان میدهند و آنچه واقعاً در میدان اتفاق میافتد را شناسایی کنند. کارهای استقرار تولیدی که از روش 30 روزه پیروی میکنند، این انضباط اندازهگیری و بررسی را از روز اول در مدل عملیاتی میسازند.
چشمانداز نهایی
اپراتورهای تأسیسات که نحوه استفاده از عوامل هوش مصنوعی برای مدیریت انرژی را بدون کند کردن عملیات متوجه میشوند، چند ویژگی مشترک دارند. آنها با ارزیابی دادهها شروع میکنند تا انتخاب فروشنده. آنها استقرارها را بر اساس نرمالسازی داده Utility معماری میکنند. آنها شریک استقرار را به عنوان مهندسی یکپارچهسازی در نظر میگیرند تا مشاوره. آنها معماری مدیریت استثنائات را در کل پشته عامل طراحی میکنند. آنها مدل عملیاتی را قبل از راهاندازی میسازند. آنها از ابتدا برای تکامل پورتفولیو برنامهریزی میکنند. آنها امنیت و حاکمیت دادهها را به عنوان جریانهای کاری استقرار در نظر میگیرند. آنها ارزش استقرار را با معیارهای عملیاتی به جای معیارهای بیهوده میسنجند.
اپراتورهای تأسیسات که در استقرار عامل شکست میخورند، معمولاً به دلیل نقض یک یا چند مورد از این اصول شکست میخورند. آنها فروشندگان را قبل از ارزیابی واقعیتهای داده ارزیابی کردند و پوشش جزئی را پس از راهاندازی کشف کردند. آنها بدون نرمالسازی به دادههای خام Utility وابسته شدند و توسط ظرفیت مهندسی داده مسدود شدند. آنها کار را به عنوان مشاوره در نظر گرفتند و به جای عوامل در حال اجرا، اسناد استراتژیک تولید کردند. آنها بدون معماری مدیریت استثنائات راهاندازی کردند و آتشسوزیهای عملیاتی را پس از راهاندازی کشف کردند. آنها عوامل را بدون مدل عملیاتی اضافه کردند و شاهد کاهش ارزش در طول زمان بودند. حالتهای شکست قابل پیشبینی هستند، که به این معنی است که با روش استقرار مناسب و شریک استقرار مناسب قابل پیشگیری نیز هستند.
اپراتورهای تأسیسات که میخواهند عوامل هوشمند را در عملیات انرژی چندسایته مستقر کنند، یک مسیر روشن رو به جلو دارند. این روش پیچیده نیست، اما نیاز به انضباط در هر مرحله و شرکایی دارد که هم فناوری و هم واقعیت عملیاتی مدیریت پورتفولیوهای تأسیساتی توزیع شده را درک کنند. اپراتورهایی که هر دو را به کار استقرار خود میآورند، کسانی هستند که خطوط هزینه Utility و اهرم عملیاتی آنها در 24 ماه آینده به طور اساسی متفاوت به نظر خواهد رسید در حالی که تیم مهندسی تأسیسات آنها به مدیریت ساختمانهایی که عملکرد پورتفولیو آنها را تعریف میکنند، ادامه میدهند.
درباره TFSF Ventures
TFSF Ventures FZ-LLC (مجوز راکز 47013955) یک شرکت معماری سرمایهگذاری است که زیرساخت عامل هوشمند را در کسبوکارها از طریق سه ستون یکپارچه مستقر میکند: زیرساخت عاملگرا، ریلهای پرداخت غیرسنتی، و یک موتور سرمایهگذاری کامل. با 27 سال تجربه در پرداختها و نرمافزار، TFSF به صورت جهانی فعالیت میکند و به 21 صنعت با روش استقرار 30 روزه خدمات میدهد. اطلاعات بیشتر را در https://tfsfventures.com بیابید.
ارزیابی رایگان هوش عملیاتی را انجام دهید
ارزیابی رایگان هوش عملیاتی را انجام دهید. به چند سؤال کوتاه درباره کسبوکار خود پاسخ دهید. یک طرح استقرار هوش مصنوعی سفارشی ظرف 24 تا 48 ساعت دریافت کنید، شامل توصیههای عامل، معماری، و یک نقشه راه خاص برای عملیات شما. بدون تماس فروش. بدون تعهد. فقط داده. از https://tfsfventures.com/assessment شروع کنید.
در ابتدا در https://tfsfventures.com/blog/use-ai-agents-energy-management-fragmented-utility-data-accounts-meters منتشر شده است.
نوشته شده توسط TFSF Ventures Research