در تحلیل فرآیند، خیلی وقت‌ها مشکل اصلی این نیست که راه‌حل نداریم؛ مشکل این است که مسئله را درست نفهمیده‌ایم. من به این مرحله می‌گویم Problem Intake؛ یعنی جایی که درخواست خام، شکایت، نشانه یا مشاهده اولیه را به یک مسئله روشن و قابل تحلیل تبدیل می‌کنیم.
اگر این مرحله ضعیف انجام شود، حتی بهترین تحلیل‌ها هم به نتیجه دقیق نمی‌رسند. چون ورودی نامشخص، خروجی نامطمئن می‌سازد. به همین دلیل، Problem Intake فقط ثبت درخواست نیست؛ بلکه فرآیند دریافت، شفاف‌سازی، قاب‌بندی و اولویت‌بندی مسئله است.
Problem Intake چه کمکی به تحلیل فرآیند می‌کند؟
Problem Intake کمک می‌کند قبل از ورود به مدل‌سازی یا بهبود، مطمئن شویم مسئله واقعی چیست.
در این مرحله مشخص می‌شود آیا با یک مشکل فرآیندی روبه‌رو هستیم، یا فقط با یک شکایت موردی، یک خطای تکرارنشدنی، یا حتی یک راه‌حل پیشنهادی که هنوز مسئله‌اش روشن نیست.
این کار باعث می‌شود تحلیلگر به‌جای کار روی حدس‌ها، روی مسئله‌ای کار کند که ارزش حل شدن دارد.
1. فرم استاندارد دریافت مسئله
یکی از ساده‌ترین و مؤثرترین روش‌های Problem Intake، استفاده از فرم استاندارد است. این فرم کمک می‌کند درخواست‌ها از همان ابتدا ساختارمند ثبت شوند.
در این فرم، بهتر است به‌جای جمله‌های کلی مثل «فرآیند مشکل دارد»، اطلاعاتی مثل مسئله دقیق، محل وقوع، اثر، شواهد، ذینفعان و هدف مورد انتظار ثبت شود.
این روش برای سازمان‌هایی مناسب است که ورودی‌های زیادی دارند و می‌خواهند قبل از تحلیل، اطلاعات را یکدست و قابل مقایسه دریافت کنند.
جهت تهیه فرم استاندارد می توانید بر روی این لینک کلیک نمایید تا وارد صفحه خرید گردید.
چه زمانی از فرم استفاده کنیم؟
وقتی درخواست‌ها پرتعداد هستند، فرایندها تکراری‌اند، و می‌خواهیم از دوباره‌کاری در جمع‌آوری اطلاعات جلوگیری کنیم.
2. تیکت و triage
اگر حجم درخواست‌ها زیاد باشد، تیکت به همراه triage یکی از بهترین روش‌هاست. در این مدل، هر درخواست ابتدا ثبت می‌شود، بعد غربال می‌شود و سپس تصمیم می‌گیریم با آن چه کنیم: ارجاع، پاسخ سریع، تحلیل بیشتر یا ورود به backlog.
این روش برای محیط‌های عملیاتی، پشتیبانی، IT و تیم‌های چابک بسیار کاربردی است.
مثلاً اگر چندین تیکت درباره تأخیر در یک فرآیند ثبت شده باشد، triage کمک می‌کند مشخص شود کدام‌ها تکراری‌اند و کدام‌ها نشانه یک مشکل ساختاری هستند.
چه زمانی از تیکت استفاده کنیم؟
وقتی تعداد درخواست‌ها بالاست و نیاز داریم تصمیم‌گیری اولیه سریع و قابل ردیابی باشد.
3. جلسه کوتاه intake
همه مسئله‌ها با فرم حل نمی‌شوند. بعضی موارد مبهم، حساس یا بین‌واحدی هستند و برای فهم آن‌ها باید یک جلسه کوتاه intake برگزار کرد.
این جلسه نباید طولانی شود. هدف این نیست که همه چیز در همان جلسه حل شود؛ هدف این است که مسئله از حالت کلی و مبهم به یک statement روشن تبدیل شود.
مثلاً وقتی کسی می‌گوید «گزارش‌ها بی‌فایده‌اند»، این جمله برای تحلیل کافی نیست. اما در یک جلسه کوتاه ممکن است روشن شود که مشکل در زمان تولید گزارش است، در کیفیت داده است، یا در تعریف شاخص‌ها.
چه زمانی جلسه intake مفید است؟
وقتی مسئله چندلایه است، ذینفعان مختلف دارد، یا احتمال سوءبرداشت در فرم بالا است.
4. Gemba Walk
یکی از بهترین روش‌ها برای فهم مسئله واقعی، Gemba Walk است؛ یعنی رفتن به محل واقعی اجرای کار و دیدن فرآیند در عمل.
من این روش را خیلی جدی می‌گیرم، چون فاصله بین «آنچه در مستندات نوشته شده» و «آنچه واقعاً انجام می‌شود» معمولاً زیاد است.
با Gemba Walk می‌توان دید تأخیر دقیقاً کجا رخ می‌دهد، دوباره‌کاری در کدام مرحله است، و آیا مشکل واقعاً در فرآیند است یا در اجرا.
چه زمانی Gemba Walk مناسب است؟
وقتی مسئله رفتاری، عملیاتی یا اجرایی است و نمی‌خواهیم فقط به گزارش‌های غیرمستقیم تکیه کنیم.
5. Process Mining
اگر داده سیستمی داشته باشیم، Process Mining یکی از دقیق‌ترین روش‌ها برای Problem Intake است. این روش از لاگ رویدادها استفاده می‌کند و نشان می‌دهد فرآیند واقعاً چگونه اجرا شده است.
این روش برای سازمان‌هایی که ERP، CRM، BPMS یا سیستم‌های تراکنشی دارند بسیار ارزشمند است.
مثلاً اگر گفته شود فرآیند صدور فاکتور طولانی شده، Process Mining می‌تواند مسیر واقعی، زمان‌های انتظار، حلقه‌های دوباره‌کاری و گلوگاه‌ها را مشخص کند.
چه زمانی Process Mining مناسب است؟
وقتی داده رویدادی داریم و می‌خواهیم مسئله را با شواهد دقیق و قابل‌سنجش بررسی کنیم.
6. Voice of Customer یا VOC
گاهی مسئله از داخل سازمان دیده نمی‌شود، اما مشتری آن را به‌وضوح حس می‌کند. در این حالت، VOC یا Voice of Customer یکی از مهم‌ترین منابع intake است.
شکایت‌ها، نظرسنجی‌ها، تماس‌های پشتیبانی و بازخوردهای فروش، همه می‌توانند نشانه یک مشکل فرآیندی باشند.
مثلاً اگر مشتریان مکرراً بگویند پاسخگویی کند است، باید این بازخورد را به زبان فرآیند ترجمه کنیم و بفهمیم مشکل در صف، منابع، اولویت‌بندی یا SLA است.
چه زمانی از VOC استفاده کنیم؟
وقتی تجربه مشتری مهم است و می‌خواهیم نشانه‌های بیرونی مشکل را به مسئله فرآیندی تبدیل کنیم.
7. SIPOC
من SIPOC را بیشتر یک ابزار قاب‌بندی مسئله می‌دانم تا صرفاً یک مدل. این ابزار کمک می‌کند مرز فرآیند را مشخص کنیم و بفهمیم مسئله در کدام بخش زنجیره قرار دارد.
SIPOC با مشخص کردن Supplier, Input, Process, Output, Customer کمک می‌کند تحلیل ما از همان ابتدا بیش از حد گسترده یا مبهم نشود.
چه زمانی SIPOC مفید است؟
وقتی نمی‌دانیم مسئله دقیقاً در کدام بخش از زنجیره ایجاد شده و نیاز داریم دامنه را شفاف کنیم.
8. 5W2H
برای کامل کردن تصویر مسئله، من معمولاً از 5W2H استفاده می‌کنم. این روش با هفت سؤال ساده، اما دقیق، باعث می‌شود مسئله را کامل‌تر ببینیم: چه کسی، چه چیزی، چه زمانی، کجا، چرا، چگونه و با چه حجمی.
این چارچوب کمک می‌کند یک مشکل کلی به یک مسئله قابل‌تحلیل تبدیل شود.
مثلاً وقتی می‌گوییم «فرآیند تأیید مرخصی کند است»، 5W2H نشان می‌دهد این کندی برای چه کسانی رخ می‌دهد، در کدام مرحله، در چه بازه زمانی و با چه اثری.
چه زمانی 5W2H را به کار ببریم؟
وقتی می‌خواهیم مسئله را از حالت توصیف عمومی به یک بیان دقیق و قابل پیگیری تبدیل کنیم.
جمع‌بندی
Problem Intake یعنی قبل از هر نوع تحلیل یا بهبود، مطمئن شویم مسئله را درست فهمیده‌ایم. برای این کار ابزارهای مختلفی داریم: فرم، تیکت، جلسه intake، Gemba Walk، Process Mining، VOC، SIPOC و 5W2H.
هیچ‌کدام از این روش‌ها به‌تنهایی کافی نیستند، اما در کنار هم یک ورودی بالغ برای تحلیل فرآیند می‌سازند.
تجربه من این است که هرچه Problem Intake بهتر طراحی شود، کیفیت تحلیل و سرعت رسیدن به راه‌حل هم بالاتر می‌رود.
محسن سیف محمدی
محسن سیف محمدی
محسن سیف محمدی
محسن سیف محمدی
محسن سیف محمدی
seifmohammadi
