اگر از این مؤلفه غافل شوید ، ابتکارات هوش مصنوعی شما شکست خواهد خورد

مکالمات من با CIO در طول سال گذشته به طرز چشمگیری تغییر کرده است. این مکالمه برای محوریت نقاط عطف تحول دیجیتال و جدول زمانی مهاجرت ابری استفاده می شود. اکنون این مربوط به نمایندگان ، گردش کار چند عامل و چگونگی مقیاس ابتکارات هوش مصنوعی فراتر از نسخه های نمایشی اثبات مفهوم است. اما این همان چیزی است که به طرز دردناکی روشن می شود: بیشتر سازمان ها در تلاشند تا آینده کار را در زیرساخت هایی بسازند که به سختی قادر به پاسخگویی به خواسته های دیروز بودند ، چه رسد به فردا.

من به عنوان یک زمینه CTO که در مراحل مختلف سفر هوش مصنوعی خود با سازمانها کار می کنم ، الگوی نگران کننده ای را می بینم. شرکت های بالغ برای پیاده سازی فن آوری های عامل جدید عجله می کنند ، فقط برای کشف سیستم های اساسی آنها هرگز برای پشتیبانی از داده ها ، سرعت ، نیازهای پردازش یا حاکمیت امنیتی که جریان کار عامل را تقاضا می کند ، مهندسی نشده اند. نتایج فقط خلبانان شکست خورده نیستند – هزینه ، ریسک و کشیدن عملیاتی که با گذشت زمان ترکیبات است.

مرتبط: سیستم های منسوخ بیش از آنچه متوجه می شوید به تجارت شما آسیب می رسانند. در اینجا نحوه مدرن سازی قبل از حملات فاجعه آورده شده است.

واقعیت زیرساخت عامل

نمایندگان و مدل ها از داده ها تغذیه می شوند و بدون ساختار مناسب ، توپولوژی شبکه و بلوک های ساختاری بنیادی در محل ، مأمورین در اطراف بیکار نشسته اند و منتظر اطلاعات هستند. ما فقط در مورد داشتن داده صحبت نمی کنیم – ما در مورد داشتن آن در قالب مناسب صحبت می کنیم ، در زمان مناسب ، با امنیت مناسب ، شفافیت و حاکمیتی که در اطراف آن پیچیده شده است.

خواسته های جهانی سازی این مسئله را پیچیده تر می کند. هنگام مقیاس بندی در جغرافیاها با الزامات حاکمیت داده های مهیج ، چگونه تکرار و قوام وقتی داده ها نمی توانند حوزه های قضایی خاصی را ترک کنند ، تضمین می شود؟ سازمان هایی که با هدف تسهیل در مقیاس آسان ، قطعات زیرساخت مدرن را به کار می گیرند ، ناگهان می توانند مشتری را سوار کنند ، به بازارهای جدید منتقل شوند و با بخشی از هزینه و تلاش خود که قبلاً استفاده می کردند ، محصولات جدید را راه اندازی کنند.

عدم تحمل یا در آغوش گرفتن وضع موجود منجر به آنچه من بدهی زیرساخت می نامم منجر می شود و علاقه را سریعتر از آنچه پیش بینی می شود جمع می کند.

تشخیص بهداشت عملیاتی

من از یک چارچوب ساده برای ارزیابی آمادگی سازمانی استفاده می کنم: مدل 60-30-10 برای مهندسی و توسعه نرم افزار. در یک سازمان فناوری اطلاعات سالم ، حدود 60 ٪ از منابع باید روی ویژگی های افزایشی “حرکت به جلو” تمرکز کنند و تجربه کاربر را که به الزامات واحد تجاری و درخواست های مشتری پاسخ می دهند ، بهبود بخشد. حدود 30 ٪ به حفظ عملیات فعلی در مناطقی مانند پشتیبانی ، رفع اشکال و عملکرد سیستم های موجود اختصاص یافته است. 10 ٪ آخر برای ابتکارات عظیم تحول که پتانسیل 10 برابر تأثیر سازمان را دارند ، باید محفوظ باشد.

وقتی این نسبت ها را می بینم ، به ویژه هنگامی که تعمیر و نگهداری به 40 یا 50 ٪ از منابع صعود می کند ، این اغلب یک مشکل معماری سیستم است که به عنوان یک مسئله عملیاتی می شود. ممکن است شما بیشتر وقت خود را صرف نگهداری نکنید زیرا کد شما ضعیف نوشته شده است ، بلکه به این دلیل است که زیرساخت های اساسی هرگز برای پشتیبانی از نیازهای فعلی طراحی نشده اند ، چه رسد به آینده. سیستم ها استرس می گیرند ، همه چیز شکسته می شود ، میانبرها گرفته می شوند و بدهی فقط جمع می شود.

اگر هر بار که توانایی جدیدی را ایجاد می کنید – انجام همان تحولات داده ، بازسازی همان ادغام ها ، در حال صعود از همان تپه هستید ، توضیح می دهید که چرا این برنامه نمی تواند از آنچه برای آن ساخته اید استفاده کنید – به احتمال زیاد پایه و اساس شما نیاز به توجه دارد.

تکامل استراتژی چند ابر

با بالغ شدن قابلیت های شما ، نیازهای ابر شما تغییر خواهد کرد. شما ممکن است در حالی که از اکوسیستم مشارکت در دیگری استفاده می کنید ، از ابزارهای شگفت انگیز AI در یک ابر استفاده کنید. ممکن است شما چند ابر به این دلیل بروید زیرا خطوط مختلف تولید نیازهای عملکرد متفاوتی دارند یا به دلیل اینکه تیم های مختلف تخصص متفاوتی دارند.

نکته اصلی حفظ تراز فناوری با رویکردهای بازتر و قابل حمل است. این به شما انعطاف پذیری می دهد تا با تغییر نیازها بین ابرها حرکت کنید. بعضی اوقات ، یک فناوری اختصاصی وجود دارد که به آنچه انجام می دهید اصلی است و شما آن را به عنوان قیمت انجام کار می پذیرید. اما هر کجا که ممکن باشد ، از قفل شدن در تصمیمات آینده خودداری کنید.

بدانید که شما به عنوان یک سازمان چه کسی هستید. اگر دانشمندان داده های شگفت انگیزی دارید اما تخصص Kubernetes را محدود می کنید ، به سمت خدمات مدیریت شده گرایش پیدا کنید که به دانشمندان داده شما اجازه می دهد تا به جای زیرساخت ها روی مدل ها تمرکز کنند. اگر تیم شما می خواهد هر شماره گیری و پارامتر را بهینه کند ، سیستم عامل هایی را انتخاب کنید که آن سطح کنترل را ارائه دهند. استراتژی ابر خود را با قابلیت های داخلی خود تراز کنید ، نه با آنچه در نسخه های نمایشی فروشنده چشمگیر است.

مرتبط: چگونه چند ابر می تواند کاتالیزور رشد نیازهای کسب و کار شما باشد

معماری داده ضروری است

قبل از اجرای هر ابتکار عمل هوش مصنوعی ، باید به سؤالات اساسی در مورد چشم انداز داده خود پاسخ دهید. داده های شما کجا ساکن است؟ چه محدودیت های نظارتی حاکم بر استفاده از آن است؟ چه سیاست های امنیتی آن را احاطه کرده است؟ عادی سازی آن در یک بستر داده یکپارچه چقدر دشوار خواهد بود؟

از نظر تاریخی ، داده ها خاک اره شده است-محصول جانبی اجتناب ناپذیر کار انجام می شود-که در آن زمان به یک مرکز هزینه تبدیل می شود که در آن شما نیاز به پرداخت مبلغ روزافزون برای ذخیره و محافظت از داده هایی که به طور فزاینده ای کمتر از آن بی ربط می شوند ، بیشتر از زمان خلقت آن دور می شوید. سازمانها غالباً کشف می کنند که داده ها را طی چندین دهه جمع کرده اند بدون اینکه ساختار یا دسترسی آن را در نظر بگیرند. این قابل قبول است که انسان اطلاعات را به صورت دستی پردازش می کند ، اما مأمورین به جریان داده های ساختاری ، حاکم و در دسترس نیاز دارند. اکنون ، داده ها ممکن است با ارزش ترین منبع سازمان باشد – هرچه منحصر به فرد تر یا تخصصی تر ، بهتر باشد. سرمایه گذاری زمان لازم برای تهیه معماری داده شما سود سهام را در هر ابتکار هوش مصنوعی بعدی پرداخت می کند.

این فقط مربوط به قابلیت های فنی نیست – بلکه مربوط به بلوغ حاکمیت است. آیا می توانید ضمن حفظ مرزهای امنیتی ، جریان داده ها را یکپارچه در جایی که باید به آنجا برود اطمینان حاصل کنید؟ آیا می توانید بدون ایجاد خطرات مربوط به انطباق ، چندین عامل را که به منابع و برنامه های مختلف داده دسترسی دارند ، هماهنگ کنید؟ آیا حتی می توانید انواع مختلفی از داده ها را از همه سیستم های فایل ، پایگاه داده ها و فروشگاه های شیء به یک نمای واحد بکشید؟

سیگنال های ارزیابی سیستم میراث

چندین شاخص نشان می دهد که زیرساخت های فعلی شما از جاه طلبی های هوش مصنوعی پشتیبانی نمی کند. اگر به جای ایجاد قابلیت های جدید ، منابع بیشتری را برای حفظ سیستم های موجود صرف می کنید ، این یک مسئله ساختاری است. اگر هر پروژه جدید نیاز به کار ادغام گسترده ای دارد که قابل استفاده مجدد نیست ، معماری شما فاقد مدولار بودن است.

هنگامی که تیم فروش شما فرصت ها را از دست می دهد زیرا ویژگی ها “در نقشه راه برای سال آینده” به جای در دسترس بودن در دسترس هستند ، شما هزینه های فرصت را برای محدودیت های فنی پرداخت می کنید. جف بزوس یک بار گفت ، “وقتی حکایات و داده ها مخالفند ، حکایات معمولاً درست هستند.” اگر به دلیل محدودیت سیستم ، داستانهایی در مورد تخصیص منابع بیش از حد ، فرصت های از دست رفته یا چریدن مشتری می شنوید ، بدون توجه به آنچه داشبورد شما نشان می دهد ، به آن سیگنال ها توجه کنید.

رویکرد تحول زیرساخت

رویکرد RIP-and-Replace بسیاری از سازمان ها را به آتش کشیده است زیرا فرض می کند همه چیز قدیمی فاقد ارزش است. رویکردهای مدرن بر روی مؤلفه سازی متمرکز می شوند – پرداختن به عناصر سیستم به صورت جداگانه ضمن حفظ تداوم عملیاتی. شما می توانید بدون از دست دادن قابلیت ها ، عملکردی را انتقال دهید ، بدون ایجاد ضرر خالص در آنچه می توانید به مشتریان تحویل دهید ، از قدیمی به جدید انتقال دهید.

این امر مستلزم تغییر نظم و انضباط در مدیریت و یک استراتژی انتقال برازنده است. شما با حفظ آنچه موفقیت آمیز بوده است ، در حال معرفی قابلیت های جدید هستید. گاهی اوقات ، این به معنای بازنویسی کامل برای استفاده از فناوری های بومی ابر است ، اما به جای جایگزینی برنامه های عمده فروشی ، نیاز به مهاجرت عملکردی دارد.

آماده سازی برای مقیاس عامل

سازمان هایی که در دوره عامل موفق خواهند شد ، کسانی هستند که خود را برای سرعت ، دسترسی به داده ها و امنیت بدون به خطر انداختن هیچ یک از این عناصر قرار می دهند. از آنجا که ما از مدل های فردی به سمت عوامل به گردش کار چند عامل منتقل می شویم ، الزامات هماهنگی از نظر نمایی پیچیده تر می شود.

داشتن جریان یکپارچه در قالب مناسب در زمان مناسب ، به یک نیاز نمایشگر تبدیل می شود. همه چیز در ضمن حفظ مرزهای امنیتی و انطباق ، با کمترین تأخیر ممکن به ادغام نیاز دارد. سیستم عامل های ابری که می توانند پاکت نامه های حاکمیت را در اطراف هر کاری که انجام می دهید ، به کاهش خطر خطای انسانی به عنوان مقیاس پیچیدگی کمک کند. سازمان هایی که واقعاً می توانند در این زمینه برتری داشته باشند ، فقط با جونز همراه نیستند. آنها جونز هستند.

مرتبط: تغییر AI: فراتر از مدل ها به سمت عوامل هوشمند

برای نمایندگان بسازید ، نه فقط برنامه ها

کارمندان شما در حال حاضر از ابزارهای هوش مصنوعی استفاده می کنند که سازمان شما آنها را مجازات کرده است یا نه. آنها در حال بارگذاری داده ها در خدمات خارجی ، استفاده از مدل ها برای کارهای کاری و یافتن راه هایی برای تولید بیشتر هستند. هرچه سریعتر بتوانید گزینه های کنترل شده و امن را برای آنها فراهم کنید ، سریعتر می توانید مرزهای مناسبی را در مورد نحوه استفاده از این ابزارها قرار دهید.

هوش مصنوعی را به خاطر داشتن ابتکارات هوش مصنوعی پیاده سازی نکنید. روی مشکلاتی که می خواهید حل کنید و اهداف مورد نیاز برای دستیابی به آن تمرکز کنید. هوش مصنوعی ابزاری قدرتمند است ، اما باید برای پرداختن به چالش های واقعی تجارت استفاده شود ، نه اینکه جعبه ای را برای هیئت مدیره خود بررسی کنید.

تصمیمات زیرساختی که امروز می گیرید تعیین می کند که آیا ابتکارات هوش مصنوعی شما مقیاس یا متوقف می شود. در دوران عامل ، هیچ یک از میانه بین داشتن پایه و اساس مناسب و داشتن یک شمع بسیار گران قیمت از اثبات مفهوم وجود ندارد که هرگز ارزش تجاری را ارائه نمی دهد.

سرعت ، داده و امنیت سیستم عصبی اجرای موفقیت آمیز هوش مصنوعی خواهد بود. به دست آوردن این تعادل فقط یک چالش فنی نیست – این یک نیاز رقابتی است.

برای باز کردن استراتژی ها برای مقیاس بندی تجارت ، افزایش درآمد و ایجاد موفقیت پایدار ، به مدیرعامل ، بنیانگذاران و اپراتورها در کنفرانس سطح بالا بپیوندید.