کارهای تکراری
تیم برای کارهای الگوپذیر زمان زیادی مصرف میکند.
AI FOR BUSINESS / ZIBATIS
اگر بخشی از کسبوکارتان کند، دستی، پراکنده یا وابسته به افراد است، ابتدا مسئله و فرایند را بررسی میکنیم؛ سپس مشخص میکنیم AI، اتوماسیون، Agent یا یک سیستم اختصاصی واقعاً کجا میتواند ارزش ایجاد کند.
لازم نیست بدانید به چه تکنولوژیای نیاز دارید.
پروژه هوش مصنوعی از جایی شروع میشود که یک اصطکاک واقعی، مالک مشخص و نتیجه قابل سنجش وجود داشته باشد.
تیم برای کارهای الگوپذیر زمان زیادی مصرف میکند.
دانش بین افراد، فایلها و سیستمها پخش است.
لید، مشتری یا Task بین مراحل گم میشود.
اطلاعات وجود دارد، اما Action مشخص نیست.
عملیات روی دانش یک یا دو نفر میچرخد.
افزایش مشتری مستقیماً نیروی انسانی بیشتری میخواهد.
جمعآوری و تحلیل اطلاعات زمانبر است.
مشتری یا تیم دائماً سؤال مشابه میپرسد.
راهحل باید از جنس مسئله باشد. گاهی بهترین انتخاب Agent است؛ گاهی اتوماسیون، بازطراحی فرایند یا حتی هیچ AIای لازم نیست.
انتخاب تکنولوژی قبل از شناخت مسئله معمولاً فقط یک ابزار دیگر به سازمان اضافه میکند.
این قابلیتها محصول آماده قفسهای نیستند؛ براساس داده، ریسک و گردش کار هر پروژه معماری میشوند.
عاملهایی با Context، Tool، Permission و Boundary مشخص.
EXAMPLEیک Agent فروش که لید را تکمیل، دستهبندی و به مسئول درست تحویل میدهد.
مشاهده مسیر تخصصی ↗رویداد → تصمیم → اقدام، با مسیر کنترل و بازیابی.
EXAMPLEپیگیری خودکار درخواستهایی که شرطهای روشن و قابل ثبت دارند.
مشاهده مسیر تخصصی ↗دانش پراکنده را به منبع قابل استفاده برای انسان و AI تبدیل میکند.
EXAMPLEپاسخ سازمانی با استناد به منبع تأییدشده.
مشاهده مسیر تخصصی ↗اتصال AI به CRM، API، Database، Website و ابزارهای موجود.
EXAMPLEخواندن وضعیت مشتری و ثبت نتیجه در CRM.
مشاهده مسیر تخصصی ↗سیستم عملیاتی برای Workflow، Reporting و Decision.
EXAMPLEاتاق فرمانی که سیگنال را به تصمیم و Task متصل میکند.
مشاهده مسیر تخصصی ↗محصول یا Web Appی که AI بخشی از تجربه اصلی آن است.
EXAMPLEابزار تخصصی با ورودی ساختاریافته، تحلیل و Human Review.
مشاهده مسیر تخصصی ↗Use Case خوب با یک فعل و یک نتیجه قابل مشاهده تعریف میشود، نه با نام تکنولوژی.
این هفت سؤال، نقطه شروع Discovery هستند. بهجای نمایش یک درصد ساختگی، نتیجه باید توضیح دهد چرا مسئله آماده پایلوت است یا چه چیزی ابتدا باید آماده شود.
چه کاری بیشترین زمان تیم را میگیرد؟
آیا این کار تکرارپذیر است؟
داده لازم برای انجامش موجود است؟
خروجی خوب را میتوان تشخیص داد؟
اگر AI اشتباه کند، هزینه خطا چقدر است؟
آیا سیستم دیگری باید درگیر شود؟
انسان باید کجا تصمیم نهایی بگیرد؟
مسئله محدود، قابل اندازهگیری و قابل تست است.
پیش از AI باید فرایند روشنتر شود.
Use Case مناسب است اما Context آماده نیست.
AI کمک میکند، اما تصمیم نهایی نباید Autonomous باشد.
AI احتمالاً اکنون بهترین سرمایهگذاری نیست.
روش زیباتیس ریسک را زود آشکار میکند و توسعه را به شواهد وابسته نگه میدارد.
مسئله، فرایند، کاربر، داده، گلوگاه و ریسک
نقش AI، ابزار، مجوز، Human Handoff و KPI
کوچکترین Use Case واقعی در محیط محدود
دقت، خطا، سرعت، پذیرش، کیفیت و نتیجه
فقط بخش اعتبارسنجیشده وارد عملیات میشود
وضعیت هر پروژه را شفاف نشان میدهیم؛ Prototype را بهجای Production معرفی نمیکنیم و نتیجه اندازهگیرینشده نمیسازیم.
کار از Outcome شروع میشود، نه Model.
دانش، دسترسی، مجوز و Human Review از ابتدا تعریف میشوند.
هیچ پروژهای فقط چون AI جذاب است Scale نمیشود.
سیستم باید با عملیات و ابزارهای موجود کار کند.
سیستم هوشمند باید برای انسان قابل فهم و قابل کنترل باشد.
هر Pilot تعریف روشن Success دارد.
کنترل فقط یک Feature امنیتی نیست؛ بخشی از معماری ارزش و اعتماد سیستم است.
AI چه چیزی را میداند و منبع معتبر کدام است؟
به چه داده و ابزاری، با چه سطح دسترسی متصل است؟
چه کاری مجاز است انجام دهد یا برای تأیید آماده کند؟
کجا باید متوقف شود و انسان تصمیم بگیرد؟
سطح دسترسی، نوع داده، محل پردازش و Logging متناسب با معماری هر پروژه تعریف میشود. در پروژههای حساس، طبقهبندی داده، PII، نگهداری، تأیید انسانی و ارائهدهندگان خارجی در Discovery بررسی میشوند.
قیمت با نام تکنولوژی تعیین نمیشود؛ دامنه Workflow، آمادگی داده، پیچیدگی اتصال، سطح ریسک و نیازهای بهرهبرداری هزینه واقعی را شکل میدهند.
پس از تشخیص مسئله، دامنه یک پایلوت محدود و معیار تصمیم برای ادامه تعریف میشود؛ نه یک ماشینحساب قیمت ساختگی.
طبیعی است؛ انتخاب راهحل بخشی از Diagnosis است.
ممکن است قدم اول، آمادهسازی دانش یا Source of Truth باشد.
هدف، جایگزینی بیدلیل نیست؛ Integration یکی از گزینههاست.
پایلوت خوب عمداً کوچک، محدود و قابل سنجش است.
نوع داده، دسترسی، Logging و تأیید انسانی در معماری تعریف میشوند.
بله؛ به همین دلیل Evaluation، Boundary و Handoff حذفشدنی نیستند.
برای کسبوکارهایی که مسئله تکرارشونده، داده یا دانش قابل دسترس، مالک مشخص و نتیجه قابل سنجش دارند. اندازه شرکت بهتنهایی معیار مناسبی نیست.
تکرارپذیری کار، آمادگی داده، امکان تشخیص خروجی خوب، هزینه خطا و نیاز به اتصال سیستمها بررسی میشود. اگر فرایند مبهم باشد، ابتدا باید آن را روشن کرد.
Agent علاوه بر تولید پاسخ، میتواند در یک نقش و محدوده مشخص از دانش و ابزار استفاده کند، وضعیت را نگه دارد، اقدام انجام دهد و در نقاط حساس کار را به انسان بسپارد.
Automation برای قواعد ثابت و قابل پیشبینی مناسب است؛ Agent وقتی مفید میشود که کار به فهم Context، اطلاعات غیرساختاریافته یا تصمیم چندمرحلهای نیاز دارد.
در صورت وجود API یا مسیر اتصال مناسب، بله. سطح دسترسی، عملیات مجاز، Logging، بازیابی و تأیید انسانی باید در معماری تعریف شوند.
اغلب نه. بسیاری از مسائل با مدل موجود، دانش سازمانی، RAG، ابزارها، قواعد و ارزیابی درست حل میشوند. آموزش مدل فقط وقتی توجیه دارد که شواهد کافی وجود داشته باشد.
RAG روشی است که پیش از پاسخ، اطلاعات مرتبط را از منابع مشخص بازیابی میکند. وقتی پاسخ باید به اسناد معتبر و بهروز سازمان متکی باشد، میتواند مناسب باشد.
زمان به آمادهبودن داده، تعداد Workflowها، اتصالها، سطح ریسک و معیارهای ارزیابی بستگی دارد. ابتدا دامنه یک پایلوت محدود تعریف میشود.
تعداد جریانها، پیچیدگی Integration، آمادگی داده، حجم دانش، سطح اختیار، رابط کاربری، ارزیابی، زیرساخت و پشتیبانی هزینه را تعیین میکنند.
وقتی مسئله روشن نیست، فرایند پایه خراب است، داده لازم وجود ندارد، خروجی قابل ارزیابی نیست یا هزینه خطا از ارزش احتمالی بیشتر است.
خطا باید از ابتدا فرض شود. Evaluation، محدودیت دسترسی، Guardrail، ثبت رخداد، Fallback و Human Handoff برای کنترل آن طراحی میشوند.
نوع داده، منبع، مالکیت، سطح دسترسی، محل پردازش، دوره نگهداری و ارائهدهندگان خارجی متناسب با معماری پروژه مشخص میشوند.
PROJECT INTAKE / AI SYSTEMS
لازم نیست بدانید چه AIای باید بسازید. مسئله، فرایند یا گلوگاه را توضیح دهید؛ بررسی میکنیم آیا AI انتخاب مناسبی است و کوچکترین نسخه قابل آزمایش چه شکلی دارد.
از مسئله شروع میکنیم، نه از ابزار.