رویکرد
شش باور غلط که سازمان شما را از هوشمندسازی دور نگه میدارد
هوشمندسازی سازمان بیش از آنکه پروژهای فناورانه باشد، تصمیمی مدیریتی است. در این یادداشت شش باور رایج را که مسیر هوشمندسازی را در سازمانهای ایرانی میبندد بررسی میکنیم و نشان میدهیم هر کدام در عمل چه هزینهای میسازد.
در گفتوگو با مدیران ارشد، هوشمندسازی سازمان معمولاً با نام یک ابزار شروع میشود: یک سامانه هوش تجاری، یک دستیار زبانی، یک پلتفرم خودکارسازی. اما در عمل، آنچه تعیین میکند سازمان از داده سود میبرد یا نه، جنس ابزار نیست؛ کیفیت تصمیمهایی است که پیش از انتخاب ابزار گرفته میشود. شش باور زیر از موانع رایجی هستند که در ادبیات شکست و استقرار پروژههای هوش مصنوعی نیز به آنها اشاره شده است (Ryseff et al., 2024; Paleyes et al., 2022).
باور اول: هوشمندسازی یک پروژه فناوری است
هوشمندسازی در ظاهر پروژهای فناورانه به نظر میرسد، اما هسته آن بازطراحی تصمیم است: چه کسی، بر پایه چه دادهای، در چه لحظهای و با چه اختیاری تصمیم میگیرد. اگر این چهار پرسش بیپاسخ بماند، خروجی پروژه چند داشبورد زیبا خواهد بود که کسی بر پایه آنها کاری نمیکند. در مطالعه RAND، تمرکز بر فناوری بهجای مسئله واقعی کاربر و سوءتفاهم درباره مسئلهای که باید حل شود، از علتهای ریشهای شکست پروژهها گزارش شدهاند (Ryseff et al., 2024).
نشانه عملی این باور ساده است: در منشور پروژه، نام سامانهها آمده اما نام تصمیمها نیامده. پیشنهاد من این است که هر طرح هوشمندسازی با فهرستی از «تصمیمهای هدف» آغاز شود، نه فهرستی از قابلیتهای نرمافزاری.
باور دوم: اول دادهها را جمع کنیم، بعد فکر میکنیم
انبار داده بزرگ بدون مسئله مشخص، در خطر تبدیل شدن به گورستان داده است. جمعآوری داده هزینه نگهداشت دارد، ریسک امنیتی میسازد و توجه تیم را مصرف میکند. رویکرد کارآمدتر، حرکت معکوس است: از تصمیم به عقب برگردید و تنها دادههایی را بسازید که آن تصمیم را تغذیه میکنند. RAND هم یادآوری میکند که دادههایی که برای انطباق یا ثبت رویداد نگهداری شدهاند، لزوماً برای مقصد تحلیلی تازه کافی نیستند (Ryseff et al., 2024).
این به معنای کوچکفکرکردن نیست. معماری داده باید توسعهپذیر باشد، اما ترتیب ساخت آن باید از مسیر ارزش عبور کند؛ نه از فهرست جدولهای موجود در سامانههای قدیمی.
باور سوم: هوش مصنوعی جایگزین فرایند معیوب میشود
اگر فرایندی مبهم، پرتناقض و بدون مالک باشد، افزودن مدل به آن تنها سرعت تولید خطا را بالا میبرد. مدلها الگوی موجود در داده را تقویت میکنند؛ اگر داده حاصل فرایند معیوب باشد، مدل هم همان معیوبی را با اطمینان بیشتری تکرار میکند.
به همین دلیل پیشنهاد میشود یک گام «بازطراحی پیش از خودکارسازی» در نظر گرفته شود: نخست فرایند ساده و قاعدهمند میشود، سپس آنچه باقی مانده خودکار میشود. این ایده ریشه در استدلال کلاسیک مهندسی مجدد فرایند دارد که بهجای خودکارسازی کارهای موجود، حذف کارهای غیرضروری را توصیه میکرد؛ در آن صورت برخی کارهای دستی اصلاً نیازی به خودکارسازی ندارند (Hammer, 1990).
باور چهارم: خرید ابزار گرانتر، ریسک را کم میکند
ابزار گران، تعهد سازمانی بزرگتری میسازد و همین تعهد، اصلاح مسیر را سختتر میکند. در فاز نخست، انتخاب ابزار سبک و قابل جایگزینی معمولاً کمریسکتر است؛ چون تصمیم معماری را به تاخیر میاندازد تا زمانی که شناخت سازمان از مسئله کاملتر شود.
- در فاز کشف: ابزارهای سبک، دادههای نمونه، چرخههای کوتاه.
- در فاز استقرار: ابزار پایدار با پشتیبانی، امنیت و مسیر نگهداشت روشن.
- در هر دو فاز: مالکیت داده و قابلیت خروج از ابزار باید حفظ شود.
باور پنجم: تیم فنی بهتنهایی میتواند این کار را انجام دهد
پروژههای هوشمندسازی در مرز میان کسبوکار و فناوری زندگی میکنند. اگر مالک مسئله از سمت کسبوکار پای میز نباشد، تیم فنی مجبور میشود درباره قواعد کسبوکار حدس بزند. هر حدس، بدهی پنهانی است که معمولاً در زمان استقرار با هزینه بیشتری ظاهر میشود. در مطالعه RAND، ناآشنایی تیم فنی با زمینه کسبوکار و ارتباط ناکافی رهبران کسبوکار با تیم داده، پرتکرارترین علت شکست گزارش شده است (Ryseff et al., 2024).
یک ساختار ساده و کارآمد، به پیشنهاد نگارنده، سه نقش دارد: مالک مسئله از کسبوکار، مالک داده از فناوری، و یک تسهیلگر که ترجمه میان این دو را بر عهده میگیرد.
باور ششم: موفقیت را بعداً اندازه میگیریم
سنجهای که پیش از شروع تعریف نشود، پس از پایان قابل دفاع نیست. پیش از نخستین خط کد، باید بدانیم چه چیزی را با چه ابزاری اندازه میگیریم و مقدار پایه امروز چقدر است. بدون خط پایه، هر بهبودی قابل انکار و هر شکستی قابل توجیه است.
سنجههای خوب معمولاً درباره فناوری نیستند: زمان چرخه فرایند، نسبت خطای بازکاری، هزینه هر تراکنش، یا سهم تصمیمهایی که با داده گرفته شدهاند.
جمعبندی
هوشمندسازی سازمان زمانی نتیجه میدهد که بهجای پرسش «چه ابزاری بخریم؟»، از پرسش «کدام تصمیم را میخواهیم بهتر بگیریم؟» شروع کنیم. پاسخ این پرسش، ابزار، معماری داده و ترتیب کارها را خودش تعیین میکند.
منابع
- Hammer, M. (1990). Reengineering work: Don’t automate, obliterate. Harvard Business Review, 68(4), 104–112.
- Paleyes, A., Urma, R.-G., & Lawrence, N. D. (2022). Challenges in deploying machine learning: A survey of case studies. ACM Computing Surveys, 55(6), 1–29. https://doi.org/10.1145/3533378
- Ryseff, J., De Bruhl, B. F., & Newberry, S. J. (2024). The root causes of failure for artificial intelligence projects and how they can succeed: Avoiding the anti-patterns of AI (RR-A2680-1). RAND Corporation. https://doi.org/10.7249/RRA2680-1