توی تحلیل سیستم، مخصوصا توی اُدو، چیزی که کاربر میگه معمولا خود مشکل نیست؛ فقط نشونه مشکله. یعنی کاربر اغلب علامت (Symptom) میگه، نه ریشه علت (Root Cause) رو.
مثلا میگه:
“سیستم کند شده”
“یه دکمه جدید بذار”
“این فرم خیلی زمان می بره”
“تایید سفارش سخت شده”
اینا برای تحلیل گر، جواب نیستن. اینا فقط نقطه شروع اند.
اصل ماجرا
تحلیل ریشه علت (Root Cause Analysis) یعنی به جای اینکه روی ظاهر مسئله کار کنیم، بریم ببینیم ته ماجرا کجا خراب شده.
یعنی نریم فوری Feature تعریف کنیم، Customization باز کنیم یا دکمه جدید طراحی کنیم.
اول باید بفهمیم مسئله از کدوم لایه اومده:
- فرآیند (
Process) - پیکربندی (
Configuration) - داده (
Data) - دسترسی (
Access Rights) - سفارشی سازی (
Customization) - کارایی (
Performance)
نکته مهم اینه که توی اُدو خیلی از درخواست هایی که ظاهرا توسعه ای هستن، در اصل مشکل تحلیلی یا پیکربندی دارن.
۵ چرا دقیقا چه کمکی می کنه؟
تکنیک 5 چرا یعنی روی یک مشکل، پشت سر هم بپرسی چرا، تا از حرف کلی کاربر برسی به علت بنیادین.
عدد 5 قانون نیست. فقط یعنی انقدر لایه را باز کن تا ریشه معلوم بشه.
این تکنیک تو اودو خیلی خوب جواب میده، چون خیلی از باگ ها و درخواست ها تو لایه اول گمراه کننده اند.
مثال توی سیستم اودو
کاربر فروش میگه: “توی اودو یه دکمه ثبت سریع بذارین، تایید سفارش خیلی کنده.”
اگه تحلیل ضعیف باشه، سریع میره سمت طراحی دکمه.
ولی تحلیل درست این شکلی فکر می کنه:
مسئله اولیه: کاربر میگه تایید سفارش کنده.
چرا 1: چرا حس می کنه کنده؟
چون بعد از تایید سفارش، ثبت نهایی 12 ثانیه طول می کشه.
چرا 2: چرا 12 ثانیه طول می کشه؟
چون موقع تایید، چند بررسی همزمان روی داده های سفارش اجرا میشه.
چرا 3: چرا این بررسی ها سنگین شده؟
چون یک Customization روی ماژول فروش (Sales) قبل از تایید، رکوردهای مشابه را کامل جستجو می کنه.
چرا 4: چرا این جستجو کنده؟
چون Search Domain سنگین شده و روی فیلد پرتکرار ایندکس (Index) مناسب نداریم.
چرا 5: چرا از اول این رو درست ندیدیم؟
چون تو تحلیل اولیه، حجم داده و رشد سفارش ها درست برآورد نشده بود.
نتیجه
پس مشکل، نبود دکمه نیست.
ریشه مشکل تو Performance و طراحی Customization هست.
یعنی راهکار واقعی می تونه اینا باشه:
- بهینه کردن
Query - بازنگری منطق
Customization - اضافه کردن
Index - کم کردن
Validationهای غیرضروری - تست با حجم واقعی داده
یه نکته خیلی مهم
تحلیل گر چراها رو می پرسه، ولی چون ها رو از جاهای مختلف جمع می کنه.
یعنی جواب همه چراها رو یه نفر نمی ده.
معمولا این شکلیه:
- لایه اول رو کاربر میگه
- لایه دوم رو خودت از روی دیدن سناریو می فهمی
- لایه سوم رو لاگ (
Log) و رفتار سیستم نشون میده - لایه چهارم رو تیم فنی یا مدیر پایگاه داده (
DBA) میگه - لایه آخر رو مستندات، تصمیم های قبلی یا طراحی اولیه، نشون میده
پس نقش تحلیل گر اینه که پازل رو بچینه، نه اینکه فقط حرف کاربر رو یادداشت کنه.
تو اُدو معمولا ریشه مشکل کجاهاست؟
تجربه ای که زیاد تکرار میشه اینه که ریشه مسائل اودو معمولا تو یکی از این نقاطه:
-
Workflow درست طراحی نشده -
Access Rights یاRecord Rules اشتباه تنظیم شده - داده ها تمیز نیستن
-
Standard Feature رو نشناختن و بی دلیل رفتن سمتCustomization - سرور یا دیتابیس زیر بار واقعی کند شده
-
Automation یاScheduled Actionها بی موقع اجرا میشن - وابستگی بین ماژول ها درست دیده نشده
Best Practiceهایی که نباید یادت بره
1) حرف کاربر رو بعنوان Requirement در نظر نگیر
- کاربر اغلب راه حل پیشنهاد میده، نه نیاز واقعی.
- تو باید نیاز رو از دل حرفش دربیاری.
2) مسئله رو قابل اندازه گیری (Measurable) کن
- اگه میگه “کنده”، باید روشن بشه یعنی چند ثانیه.
- اگه میگه “سخته”، باید روشن بشه دقیقا کدوم مرحله اذیت می کنه.
3) اول Standard رو چک کن
- توی اودو قبل از هر سفارشی سازی (
Customization) باید مطمئن بشی که قابلیت استاندارد جواب نمی ده. - این یکی از پرتکرارترین جاهاییه که پروژه الکی سنگین میشه.
4) با داده واقعی نگاه کن
- خیلی از تحلیل ها روی دیتای کم، فریب دهنده هستن.
- مسئله اصلی معمولا وقتی خودش رو نشان میده که رکوردها زیاد میشن.
5) اثر تغییر رو بین ماژول ها ببین
- تو اودو، فروش فقط فروش نیست.
- ممکنه تغییر توی ماژول فروش (
Sales) روی ماژول خرید (Purchase)، ماژول انبار (Inventory) و ماژول حسابداری (Accounting) هم اثر بذاره.
6) بین Issue و Solution فاصله نگه دار
تا وقتی علت ریشه روشن نشده، وارد طراحی راهکار نشو.
اشتباه هایی که خیلی پیش میاد
یکی از خطاهای رایج اینه که تحلیل گر با اولین شکایت کاربر، بک لاگ توسعه باز می کنه. این کار توی اودو خیلی خطرناکه، چون ممکنه مسئله اصلا با تنظیمات، Workflow یا Data حل بشه.
یکی دیگه اینه که فقط لایه فنی رو می بینن. در حالی که خیلی وقت ها ریشه مشکل اصلا تو کد نیست؛ تو فرآینده (Process) که درست چیده نشده.
یه اشتباه مهم دیگه هم اینه که فقط همون صفحه یا همان عملیات بررسی میشه. در صورتی که تو ERP باید End to End نگاه کنی. یعنی از اول جریان تا آخرش را ببینی.
این فرمول رو توی ذهنت داشته باش
وقتی کاربر یک درخواست میگه، تو ذهنت این ترتیب را نگه دار:
- این شکایته یا نیاز؟
- این علامته یا علت؟
- این مسئله توی کدوم ماژول دیده میشه؟
- اثرش روی کدوم فراینده؟
- میشه اندازه اش کرد؟
- توی استاندارد اودو راهی براش هست؟
- اگه نه، ریشه اش
Data است یاProcess یاConfiguration یاCustomization یاPerformance؟
خلاصه اینکه توی اودو نباید از روی اولین جمله کاربر، راه حل بسازی. اول باید با تحلیل ریشه علت (Root Cause Analysis) و تکنیک 5 چرا برسی به مسئله واقعی. خیلی وقت ها چیزی که کاربر میخواد، اصلا چیزی نیست که باید ساخته بشه.
تحلیل گر خوب کسیه که بین علامت (Symptom) و ریشه علت (Root Cause) فرق بذاره.