شکافی که اکثر تصمیم‌ها ازش می‌افتن
یکی از چالش‌های اصلی در مدیریت، توسعه‌ی محصول و طراحی کسب‌وکار، تبدیل ایده‌ها و تصمیم‌های ذهنی به یک مسیر مشخص، ساختاریافته و قابل‌اجراست.
برای نمونه، ممکنه یک تیم بگه:
• ما باید وارد بازار جدید بشیم.
• محصول باید برای مشتری ساده‌تر بشه.
• برند باید حس اعتماد بیشتری ایجاد کنه.
• یا این ایده می‌تونه به یک کسب‌وکار بزرگ تبدیل بشه.
همه‌ی این‌ها می‌تونن ایده‌های درستی باشن، اما هنوز یک سؤال مهم وجود داره:
بر چه اساسی باید این تصمیم‌ها رو اجرا کنیم؟
اینجاست که فاصله بین مفهوم و اجرا خودش رو نشان می‌ده.
استراتژی، ایده، هویت و چشم‌انداز در ابتدا مفاهیمی ذهنی هستن. برای اینکه بشه روی اون‌ها تصمیم گرفت یا سرمایه‌گذاری کرد، باید به سؤال‌های مشخص‌تری تبدیل بشن:
• چه مسئله‌ای رو حل می‌کنیم؟
• برای چه کسی؟
• چرا این مسئله مهمه؟
• چه شواهدی داریم که مشتری این مشکل رو داره؟
• کدام فرضیات هنوز اثبات نشدن؟
• ریسک اصلی تصمیم کجاست؟
• و قدم بعدی چی باید باشه؟
خیلی از تیم‌ها ابزار مشخصی برای تبدیل این مفاهیم ذهنی به سؤال‌ها و تصمیم‌های ساختاریافته ندارن.
در نتیجه، بخشی از تصمیم‌های مهم بر اساس تجربه‌ی شخصی، حدس یا هیجان لحظه‌ای گرفته می‌شن. می‌شه اسم این وضعیت رو گذاشت «نقاب شهود».
یعنی:
مشکل خود شهود نیست. تجربه و شهود یک متخصص می‌تونه بسیار ارزشمند باشه. مشکل از جایی شروع می‌شه که شهود جای تحلیل، داده و اعتبارسنجی رو بگیره.
این وضعیت یکی از دلایل اصلی هدررفتن زمان، بودجه و ظرفیت تیم در پروژه‌هاست.
فلسفه‌ی مهندسی ابزارهای استراتژیک از همین نقطه شروع می‌شه.
هدف این نیست که فقط یک فرم طراحی کنیم و از کاربر اطلاعات بگیریم.
هدف اینه که سیستمی بسازیم که:
فکرهای پراکنده رو به داده، داده رو به تحلیل، تحلیل رو به تصمیم و تصمیم رو به اقدام تبدیل کنه.
یعنی چیزی که اول فقط یک ایده یا برداشت ذهنیه، در نهایت باید به یک ساختار قابل‌سنجش، قابل‌تحلیل و قابل‌دفاع تبدیل بشه.
این ابزارها چه کاربردی دارن؟
کار اصلی یک ابزار استراتژیک فقط ذخیره‌کردن اطلاعات نیست.
این ابزار باید کمک کنه تصمیم‌ها از حالت «فکر می‌کنم این درسته» خارج بشن و به تصمیم‌هایی تبدیل بشن که بشه منطق پشت اون‌ها رو توضیح داد.
حاکمیت مهندسی به‌جای سلیقه‌ی شخصی
وقتی نقشه‌راه یک کسب‌وکار فقط بر اساس نظر شخصی مدیر، بنیان‌گذار یا مشاور ساخته بشه، بخش زیادی از تصمیم به تجربه و قضاوت فردی وابسته می‌مونه.
اما وقتی تصمیم از داخل یک فرآیند تحلیلی مشخص بیرون میاد، می‌شه توضیح داد که چرا این مسیر انتخاب شده.
برای نمونه می‌شه مشخص کرد:
• چه داده‌ای بررسی شده،
• چه فرضیاتی وجود داشته،
• کدام فرضیات هنوز اثبات نشدن،
• چه ریسک‌هایی شناسایی شدن،
• و چرا یک گزینه نسبت به گزینه‌های دیگه اولویت داشته.
در این حالت، تصمیم دیگه فقط یک نظر نیست؛ یک استدلال قابل بررسی پشت اون وجود داره.
این موضوع در ارتباط با شریک، کارفرما، مدیر یا سرمایه‌گذار اهمیت زیادی داره.
چون به‌جای اینکه بگیم:
«به نظر من این بهترین مسیره»
می‌تونیم توضیح بدیم:
«با توجه به این داده‌ها، این فرضیات و این سطح از ریسک، فعلا این مسیر منطقی‌تره.»
این همون چیزیه که می‌شه ازش به‌عنوان حاکمیت مهندسی در تصمیم‌گیری یاد کرد؛ یعنی تصمیم تا جای ممکن بر اساس یک فرآیند مشخص گرفته بشه، نه فقط سلیقه‌ی فردی.
مهار ابهام قبل از تخصیص بودجه
قبل از اینکه یک تصمیم وارد مرحله‌ی اجرا بشه، باید بفهمیم چقدر درباره‌ی اون مطمئنیم.
فرض کنید یک تیم تصمیم گرفته محصولی برای یک گروه خاص از مشتریان بسازه.
قبل از توسعه، چند سؤال مهم وجود داره:
• آیا این مشتری مشکل موردنظر رو داره؟
• آیا می‌دانیم این مشکل براش مهمه؟
• آیا حاضر می‌شه برای حلش پول بده؟
• آیا راه‌حل فعلی بازار ناکافیه؟
اگر جواب این سؤال‌ها هنوز مشخص نیست، ما با «ابهام» روبه‌رو هستیم.
حالا باید یک عامل دیگه رو هم بررسی کنیم: هزینه‌ی اشتباه.
ممکنه یک فرض هنوز اثبات نشده باشه، ولی تست‌کردنش فقط چند ساعت وقت ببره. این ریسک بزرگی نیست.
اما ممکنه یک فرض اثبات‌نشده باعث بشه تیم چند ماه توسعه انجام بده و بودجه‌ی زیادی خرج کنه. اینجا موضوع جدی می‌شه.
پس سیستم باید دو چیز رو کنار هم بسنجه: میزان ابهام و هزینه‌ی اشتباه بودن فرض.
فرض‌هایی که هم ابهام زیادی دارن و هم در صورت اشتباه بودن هزینه‌ی زیادی ایجاد می‌کنن، باید قبل از اجرا در اولویت تحقیق و اعتبارسنجی قرار بگیرن.
به زبان ساده: قبل از اینکه برای یک تصمیم پول خرج کنیم، باید بفهمیم کدام بخش اون تصمیم هنوز بر پایه‌ی حدسه.
فیلتر سخت‌گیرانه‌ی فوریت درد مشتری
داشتن یک مشکل به‌تنهایی دلیل کافی برای ساخت محصول نیست.
بیشتر آدم‌ها ده‌ها مشکل دارن، اما حاضر نیستن برای حل همه‌ی اون‌ها پول پرداخت کنن یا رفتار خودشون رو تغییر بدن.
بنابراین سؤال اصلی فقط این نیست که: «آیا مشتری مشکل داره؟»
سؤال مهم‌تر اینه: این مشکل چقدر برای مشتری جدیه؟
یک مسئله زمانی ارزش سرمایه‌گذاری بیشتری پیدا می‌کنه که چند ویژگی رو هم‌زمان داشته باشه.
اول اینکه فوری باشه. یعنی مشتری حل مسئله رو به آینده موکول نکنه و همین حالا دنبال راه‌حل باشه.
دوم اینکه اجتناب‌ناپذیر باشه. یعنی نادیده‌گرفتن مسئله برای مشتری هزینه، دردسر یا پیامد مشخصی ایجاد کنه.
سوم اینکه راه‌حل‌های فعلی نتونن مسئله رو به‌خوبی حل کنن. یعنی مشتری ابزار یا روش‌هایی داشته باشه، اما همچنان از نتیجه ناراضی باشه.
و چهارم اینکه بازار هنوز راه‌حل مناسبی ارائه نکرده باشه. یعنی بین نیاز واقعی مشتری و چیزی که الان در بازار وجود داره، هنوز فاصله وجود داشته باشه.
هرچه این چهار عامل بیشتر کنار هم قرار بگیرن، احتمال اینکه با یک مسئله‌ی واقعی و قابل‌تجاری‌سازی روبه‌رو باشیم بیشتر می‌شه. البته نبود یکی از این عوامل به معنی شکست ایده نیست، اما می‌تونه جذابیت بازار و احتمال پذیرش محصول رو کاهش بده.
پس باید بین دو چیز تفاوت قائل بشیم:
اتکا به چارچوب‌های استاندارد رفتارشناسی و روایی، نه فرمول‌های ساختگی
اگر یک ابزار استراتژیک قراره رفتار مشتری، پذیرش محصول یا کیفیت پیام رو تحلیل کنه، نباید چند امتیاز و فرمول دلخواه داخل سیستم تعریف کنیم و بعد اون‌ها رو به‌عنوان تحلیل علمی ارائه بدیم.
منطق تحلیل باید تا جای ممکن به چارچوب‌هایی متصل باشه که مبنای مشخص و قابل‌دفاعی دارن.
یکی از این چارچوب‌ها Fogg Behavior Model یا مدل رفتاری فاگه.
این مدل با رابطه‌ی B=MAP توضیح داده می‌شه.
ایده‌ی اصلیش اینه که برای شکل‌گیری یک رفتار، سه عامل باید در زمان مناسب کنار هم قرار بگیرن: Motivation، Ability و Prompt.
یعنی کاربر باید انگیزه‌ی انجام کار رو داشته باشه، انجام اون کار براش ممکن و به‌اندازه‌ی کافی ساده باشه و در زمان مناسب محرک لازم رو دریافت کنه.
برای نمونه، ممکنه مشتری به یک محصول نیاز جدی داشته باشه، اما فرآیند استفاده از اون بیش از حد پیچیده باشه.
اینجا مشکل از انگیزه نیست؛ مشکل از Ability یا توانایی انجام رفتار میاد.
مدل COM-B هم رفتار رو از سه زاویه بررسی می‌کنه: Capability، Opportunity و Motivation.
این مدل کمک می‌کنه بفهمیم چرا یک رفتار اتفاق نمی‌افته.
برای نمونه، ممکنه کاربر انگیزه داشته باشه و حتی نحوه‌ی استفاده از محصول رو هم بلد باشه، اما شرایط محیطی یا سازمانی اجازه‌ی استفاده بهش نده.
پس عدم استفاده همیشه به معنی عدم علاقه نیست.
در لایه‌ی پیام و ارتباطات هم ساختار StoryBrand کمک می‌کنه پیام محصول از زاویه‌ی مشتری طراحی بشه.
در این مدل، مشتری قهرمان اصلی داستانه و برند یا محصول نقش راهنما رو داره.
یعنی به‌جای اینکه فقط بگیم محصول ما چه قابلیت‌هایی داره، باید روشن کنیم:
• مشتری چه مسئله‌ای داره،
• می‌خواد به چه نتیجه‌ای برسه،
• چه مانعی جلوی راهشه،
• و محصول ما چطور بهش کمک می‌کنه از وضعیت فعلی به نتیجه‌ی موردنظر برسه.
معماری فنی: تفکیک دغدغه‌ها
تا اینجا درباره‌ی منطق استراتژیک سیستم صحبت کردیم. اما اگر بخوایم چنین سیستمی رو بسازیم، معماری فنی اون هم اهمیت زیادی پیدا می‌کنه.
اصل ماجرا ساده و مشخصه: هر بخش از سیستم باید مسئولیت مشخصی داشته باشه و محدوده‌ی وظایفش به‌طور دقیق تعریف بشه.
رابط کاربری باید مسئول نمایش و تعامل با کاربر باشه.
موتور قواعد باید مسئول ارزیابی قوانین و تصمیم‌ها باشه.
مدل داده باید مسئول نگهداری ساختار اطلاعات و روابط باشه.
اگر همه‌ی این وظایف داخل یک بخش از برنامه ترکیب بشن، ممکنه ساخت نسخه‌ی اولیه سریع‌تر باشه؛ اما هرچه سیستم بزرگ‌تر بشه، تغییر، توسعه و نگهداری اون سخت‌تر می‌شه.
رابط کاربری، مستقل از منطق سیستم
برای کاربر نهایی، تجربه باید ساده، روان و مرحله‌به‌مرحله باشه.
اما پشت این تجربه‌ی ساده، نباید تمام سؤال‌ها و فیلدها مستقیم داخل کد فرانت‌اند نوشته شده باشن.
فرض کنید ابزار ما صد سؤال مختلف داره.
اگر تک‌تک این سؤال‌ها داخل کد رابط کاربری نوشته شده باشن، هر بار که بخوایم یک سؤال اضافه کنیم، حذف کنیم یا ترتیب مراحل رو تغییر بدیم، باید دوباره کد فرانت‌اند رو تغییر بدیم.
راه بهتر اینه که ساختار سؤال‌ها مستقل از رابط کاربری ذخیره بشه.
رابط فقط اطلاعات ساختاریافته رو دریافت می‌کنه و بر اساس اون تصمیم می‌گیره چه چیزی نمایش بده.
برای نمونه، ساختار مشخص می‌کنه:
• این سؤال متنیه،
• این یکی چندگزینه‌ایه،
• این یکی باید عدد دریافت کنه،
• و این سؤال فقط زمانی نمایش داده بشه که کاربر در مرحله‌ی قبل پاسخ مشخصی داده باشه.
در این معماری، رابط کاربری بیشتر نقش «رندرکننده» رو داره.
مزیتش اینه که تغییر متدولوژی به صورت الزام به معنی بازنویسی رابط نیست.
این موضوع برای ابزارهای استراتژیک مهمه، چون ساختار سؤال‌ها و مدل تحلیل در طول زمان تغییر می‌کنن.
موتور قواعد، جدا از منطق اصلی برنامه
قوانین تصمیم‌گیری هم نباید در بخش‌های مختلف کد اصلی پراکنده باشن.فرض کنیم یکی از قوانین سیستم اینه: «اگر ایده B2B بود، ماژول زنجیره‌ی خرید سازمانی فعال بشه.»
اگر چنین قوانینی مستقیم در کد اصلی برنامه نوشته بشن، با زیادشدن قوانین، برنامه پر از شرط‌های مختلف می‌شه. بعد از مدتی تشخیص اینکه چه قانونی روی چه بخشی اثر می‌ذاره سخت می‌شه.
بهتره این قوانین در یک لایه‌ی مستقل به اسم Rules Engine نگهداری بشن.
موتور قواعد وظیفه داره شرایط رو بررسی کنه و بر اساس قوانین تعریف‌شده تصمیم بگیره چه اتفاقی باید بیفته.
برای نمونه:
• اگر شرط A و شرط B برقرار بودن، بخش X فعال بشه.
• اگر حداقل یکی از شروط C، D یا E برقرار بود، مسیر Y نمایش داده بشه.
• اگر امتیاز ریسک از مقدار مشخصی بیشتر شد، مرحله‌ی اعتبارسنجی اجباری بشه.
در این صورت، منطق تصمیم‌گیری از بخش‌های فنی رابط و پردازش اصلی برنامه جدا می‌مونه.
یک Rules Engine مناسب باید بتونه شرط‌های ترکیبی و تودرتو رو هم مدیریت کنه.
همچنین اگر برای اجرای یک قانون به اطلاعات بیرونی نیاز داشته باشه، باید بتونه اون اطلاعات رو دریافت کنه و در صورت نیاز نتیجه رو Cache کنه تا برای یک داده‌ی تکراری چند بار درخواست مشابه ارسال نشه.
هدف اصلی این تفکیک اینه که قواعد استراتژیک سیستم، مستقل از جزئیات فنی نرم‌افزار مدیریت بشن.
مدل داده، بدون تکرار بنیادین
مدل داده مشخص می‌کنه اطلاعات داخل سیستم چطور ذخیره می‌شن و چه ارتباطی با هم دارن. اگر ابزار طراحی‌شده ساده باشه، ممکنه مدل رابطه‌ای معمولی به‌تنهایی کافی باشه. اما وقتی تعداد رابطه‌های چندبه‌چند زیاد می‌شه، ساختار پیچیده‌تر می‌شه.
فرض کنید یک سؤال در پنج بخش مختلف سیستم استفاده می‌شه.
اگر برای هر بخش یک نسخه‌ی جدا از سؤال ذخیره کنیم، پنج کپی از یک مفهوم خواهیم داشت.
حالا اگر متن یا منطق سؤال تغییر کنه، باید همه‌ی نسخه‌ها اصلاح بشن.
در یک مدل گرافی، می‌تونیم خود سؤال رو فقط یک بار به‌عنوان یک گره مستقل ذخیره کنیم.بعد هر بخشی که به اون سؤال نیاز داره، فقط یک رابطه به همون گره ایجاد می‌کنه.
برای نمونه:
• سؤال A به بخش «اعتبارسنجی بازار» متصله.
• همون سؤال A به بخش «تحلیل ریسک» هم متصله.
• اما خود سؤال فقط یک بار در سیستم وجود داره.
• همین منطق برای دسته‌بندی ایده‌ها هم کاربرد داره.
یک ایده می‌تونه هم‌زمان:
• B2B باشه،
• در حوزه‌ی سلامت فعالیت کنه،
• ریسک بالایی داشته باشه،
• و در مرحله‌ی اعتبارسنجی بازار قرار گرفته باشه.
در مدل گرافی، لازم نیست برای هرکدوم از این ویژگی‌ها یک نسخه‌ی جدید از ایده ایجاد کنیم. فقط رابطه‌های مختلف به همان ایده متصل می‌شن.
برای توضیح بیشتر مدل گرافی، یه ایده یا موجودیت اصلی فقط یک‌بار ایجاد می‌شه و ویژگی‌ها و ارتباطات مختلف به همان موجودیت متصل می‌شن. یعنی به‌جای اینکه برای هر حالت یا ویژگی یک نسخه‌ی جداگانه از یک داده بسازیم، فقط رابطه‌های جدیدی بین داده‌های موجود تعریف می‌کنیم.
کنترل و مالکیت داده‌های استراتژیک
داده‌ای که کاربر داخل یک ابزار استراتژیک وارد می‌کنه، اطلاعات ساده‌ای مثل نام و ایمیل نیست. ممکنه درباره‌ی مدل درآمدی، استراتژی قیمت‌گذاری، ضعف رقبا، برنامه‌ی ورود به بازار، فرضیات رشد یا ریسک‌های اصلی کسب‌وکار صحبت کنیم.
این اطلاعات می‌تونن بخشی از مهم‌ترین دارایی‌های فکری یک کسب‌وکار باشن.
به همین دلیل، حریم خصوصی نباید در انتهای پروژه به‌عنوان یک قابلیت اضافی در نظر گرفته بشه.
از ابتدا باید مشخص باشه:
• داده کجا ذخیره می‌شه؟
• چه کسی بهش دسترسی داره؟
• چه زمانی به سرور منتقل می‌شه؟
• و کاربر چقدر روی این انتقال کنترل داره؟
در معماری‌هایی که امکانش وجود داره، داده می‌تونه به‌صورت پیش‌فرض روی مرورگر یا دستگاه خود کاربر ذخیره و پردازش بشه.
انتقال اطلاعات به سرور یا سرویس‌های بیرونی هم فقط زمانی انجام بشه که واقعاً نیاز وجود داشته باشه یا کاربر اجازه‌ی مشخص داده باشه.
به زبان ساده: داده‌های استراتژیک سیستم باید طوری طراحی بشن که مالکیت و کنترل آن‌ها همچنان در اختیار کاربر باشه، نه اینکه به ساختار یا محدودیت‌های داخلی سیستم وابسته باشه.
این موضوع فقط به امنیت مربوط نمی‌شه؛ بلکه روی نحوه‌ی طراحی معماری محصول و میزان اعتمادی که کاربر به سیستم پیدا می‌کنه هم تأثیر می‌ذاره.
هزینه‌های این رویکرد معماری
انعطاف‌پذیری بالای این معماری مزایای خودش رو داره، اما بدون هزینه هم نیست. هرچه به کاربر آزادی عمل بیشتری برای تغییر و مدیریت داده‌ها بدیم، طراحی، توسعه و نگهداری سیستم هم پیچیده‌تر می‌شه.
در معماری نرم‌افزار، انعطاف بیشتر همیشه با مسئولیت و هزینه‌ی فنی بیشتری همراهه.
استفاده از پایگاه‌داده‌ی گرافی، Rules Engine مستقل و چند لایه‌ی جدا زمانی منطقیه که سیستم به این سطح از پیچیدگی نیاز داشته باشه.
اگر ابزار فقط بیست سؤال ثابت داره و قرار نیست قوانین یا مسیرهای زیادی داشته باشه، استفاده از یک معماری بسیار پیچیده به احتمال زیاد ارزش اقتصادی نداره.
در این شرایط، معماری تبدیل به Overengineering می‌شه؛ یعنی هزینه‌ی ساخت و نگهداری سیستم بیشتر از ارزشی می‌شه که این پیچیدگی ایجاد می‌کنه.
تفکیک لایه‌ها خودش هزینه‌ی نگهداری داره.
ممکنه یک تغییر در متدولوژی نیاز داشته باشه در ساختار داده، موتور قواعد و رابط کاربری هم‌زمان بررسی بشه.
پس معماری ماژولار به‌خودی‌خود به معنی معماری کم‌هزینه نیست؛ بیشتر به معنی معماری قابل‌کنترل‌تر در مقیاس بالاتره.
قابلیت تغییر قوانین بدون کدنویسی مجدد هم همین وضع رو داره.
این قابلیت قدرت زیادی می‌ده، اما اگر Versioning، اعتبارسنجی و تست خودکار وجود نداشته باشه، یک قانون اشتباه می‌تونه رفتار چند بخش سیستم رو تغییر بده.
برای همین، Rules Engine فقط به محیط ویرایش قانون نیاز نداره؛ به مکانیزم کنترل تغییر هم نیاز داره.
موضوع مهاجرت داده هم مهمه.
اگر یک تیم ابتدا سیستم ساده‌ای داشته باشه و بعد بخواد به مدل جدید مهاجرت کنه، باید مشخص باشه اطلاعات قبلی چطور به ساختار جدید منتقل می‌شن.
اگر این مسیر از ابتدا در نظر گرفته نشه، مهاجرت داده می‌تونه خودش تبدیل به یک پروژه‌ی جدا و پرهزینه بشه.
هدف نهایی این فلسفه معماری
در نهایت، ارزش یک پلتفرم تصمیم‌گیری استراتژیک با تعداد فرم‌ها یا حجم داده‌ای که جمع می‌کنه مشخص نمی‌شه.
سؤال اصلی اینه: بعد از اینکه کاربر همه‌ی این اطلاعات رو وارد کرد، سیستم چه چیزی بهش تحویل می‌ده؟
اگر خروجی فقط مجموعه‌ای از جواب‌های ثبت‌شده باشه، ما هنوز یک ابزار جمع‌آوری اطلاعات داریم.
یک سیستم استراتژیک واقعی باید اطلاعات رو پردازش کنه و به خروجی‌هایی تبدیل کنه که کاربر بتونه مستقیم از اون‌ها برای تصمیم‌گیری و اجرا استفاده کنه.
برای نمونه:
• یک بریف اولیه‌ی یک‌صفحه‌ای که مشخص کنه ایده چیه، مشتری کیه و مسئله‌ی اصلی کجاست،
• یک سند الزامات محصول و فنی که مشخص کنه چه چیزی باید ساخته بشه،
• یک بوم مدل کسب‌وکار همراه با اقتصاد واحد که منطق درآمد و هزینه رو روشن کنه،
• یک دفترچه‌ی ثبت ریسک که مشخص کنه کدوم فرضیات هنوز اشتباه یا مبهم و اثبات‌نشده‌ان،
• یک برنامه‌ی اعتبارسنجی که بگه هر فرض رو چطور باید آزمایش کرد،
• و یک نقشه‌راه اولویت‌بندی‌شده که مشخص کنه تیم از اینجا به بعد چه کارهایی رو و با چه ترتیبی انجام بده.
در واقع، سیستم باید کاربر رو از یک مسیر مشخص عبور بده:
ایده → سؤال → داده → تحلیل → تصمیم → اقدام.
این همون تفاوت بین یک فرم پیشرفته و یک سیستم تصمیم‌گیریه.
فرم از کاربر اطلاعات می‌گیره؛ اما سیستم تصمیم‌گیری باید از اون اطلاعات، منطق، اولویت و اقدام بسازه.
تا وقتی یک ابزار نتونه این فاصله رو پوشش بده، هرچقدر هم داشبورد حرفه‌ای، فرم‌های زیاد یا تحلیل‌های پیچیده داشته باشه، هنوز بیشتر یک ابزار جمع‌آوری اطلاعاته تا یک سیستم واقعی برای تصمیم‌گیری استراتژیک.
