مدیریت کار، پروژه و عملکرد به‌عنوان یکی از بخش‌های ERP، نه تعریف کل محصول نقطهٔ شروعی برای شناخت درست دامنهٔ یک سامانهٔ سازمانی است. وقتی مسئلهٔ امروز سازمان، پیگیری کارها یا روشن‌کردن مسئولیت اعضای تیم است، می‌توان بررسی را از همین بخش آغاز کرد؛ اما نباید نیاز فعلی را با تمام هویت محصول یکسان دانست. در این راهنما، مرز مدیریت کار و پروژه را مشخص می‌کنیم، برای بررسی عملکرد پرسش‌های عملی پیشنهاد می‌دهیم و جایگاه این بخش را در آسای آفیس توضیح می‌دهیم.
مدیریت کار، پروژه و عملکرد به‌عنوان یکی از بخش‌های ERP، نه تعریف کل محصول
در راهنمای ماژول‌های ERP، مدیریت پروژه در کنار مدیریت مالی، سرمایهٔ انسانی، زنجیرهٔ تأمین، ارتباط با مشتری و حوزه‌های دیگر آمده است. همین دسته‌بندی، تمایز مهمی را روشن می‌کند: مدیریت پروژه یکی از بخش‌های قابل بررسی در ERP است، نه نام دیگری برای کل آن.
برای انتخاب یا ارزیابی سامانه، دو پرسش را جدا نگه دارید: «اکنون کدام مسئله را می‌خواهیم حل کنیم؟» و «محصول چه دامنه‌ای دارد؟» پاسخ پرسش نخست ممکن است سامان‌دادن کارهای یک واحد باشد؛ پاسخ پرسش دوم باید بر شناخت هویت محصول و ماژول‌های مستند آن تکیه کند. همچنین، وجود یک ماژول در معرفی محصول را معادل فعال‌بودن آن برای سازمان خود نگیرید.
مدیریت کار چه چیزی را باید روشن کند؟
در مستندات فنی یک ماژول مدیریت کار، چرخهٔ کار از تعریف و برنامه‌ریزی تا تخصیص، پایش پیشرفت و تکمیل توصیف شده است. متن همچنین از کارهای مستقل، هماهنگی کار میان تیم‌ها، وابستگی‌ها و ثبت زمان و نتایج کار سخن می‌گوید. این توصیف، نمونه‌ای مستند از دامنهٔ مدیریت کار است؛ نباید آن را فهرست قابلیت‌های همهٔ سامانه‌ها یا آسای آفیس تلقی کرد.
برای بررسی نیاز سازمان خود، پیشنهاد می‌شود هر کار را با چند پرسش روشن کنید: خروجی چیست، چه کسی مسئول آن است، چه زمانی باید تحویل شود و چه کسی نتیجه را می‌پذیرد؟ سپس بررسی کنید کدام اطلاعات واقعاً باید در سامانه ثبت شود. هدف این بررسی، تهیهٔ فهرست بلند قابلیت‌ها نیست؛ هدف، مشخص‌کردن اطلاعات لازم برای پیگیری یک کار واقعی است.
از کار مستقل تا پروژه
برای طراحی فرایند، ابتدا کارهای مستقل را از مجموعه‌کارهایی که باید هماهنگ پیش بروند جدا کنید. مثلاً پاسخ‌دادن به یک درخواست داخلی را می‌توان در سطح یک کار بررسی کرد؛ اما آماده‌سازی مجموعه‌ای از خروجی‌ها با مسئولان متفاوت را بهتر است به‌صورت یک سناریوی پروژه‌ای تحلیل کنید. این یک پیشنهاد برای صورت‌بندی نیاز است، نه ادعای وجود ساختار یا قابلیت مشخص در محصول.
عملکرد را چگونه بررسی کنیم؟
در ارزیابی داخلی، پیشنهاد می‌شود «وضعیت کار» و «قضاوت دربارهٔ عملکرد» را دو موضوع جدا در نظر بگیرید. مشخص کنید برای بررسی عملکرد، چه شواهدی لازم دارید: نتیجهٔ تحویل‌شده، معیار پذیرش، توضیح تأخیر یا بازخورد مسئول بررسی؟ اگر ثبت زمان هم جزو نیازهاست، ابتدا هدف آن را روشن کنید و وجود این قابلیت را در استقرار موردنظر جداگانه بررسی کنید. در این مقاله، صرف بسته‌شدن کار یا ثبت ساعت، معادل ارزیابی کامل عملکرد فرض نمی‌شود.
جایگاه مدیریت کار و پروژه در آسای آفیس
آسای آفیس، سکوی یکپارچه و ماژولار ERP سازمانی و مدیریت عملیات سازمان است؛ نه صرفاً ابزار مدیریت وظیفه یا تسک‌منیجر. این محصول هستهٔ سازمانی، ساختار و چارت سازمان، گردش‌کارها و دستیار هوش مصنوعی دارد و قابلیت‌های آن در قالب ماژول‌های قابل فعال‌سازی ارائه می‌شوند.
مدیریت کار، عملکرد و پروژه در حوزهٔ مدیریت سرمایهٔ انسانی آن قرار می‌گیرند. حوزه‌های دیگر محصول شامل مدیریت ارتباط با مشتری، مالی، حسابداری، تأمین و لجستیک، مدیریت دانش و آموزش، مکاتبات اداری و دبیرخانه، و روابط عمومی و انتشار است. بنابراین، معرفی آسای آفیس فقط با فهرست وظایف، توصیف کاملی از هویت آن نیست.
بااین‌حال، فعال‌بودن هر ماژول به استقرار، اشتراک و دسترسی همان سازمان بستگی دارد. حضور و غیاب و حقوق‌ودستمزد نیز در استقرارها و سازمان‌های دارای دسترسی مطرح‌اند. از این معرفی نباید اتصال خودکار داده‌ها یا گردش مشخصی میان ماژول‌ها نتیجه گرفت؛ هر سناریوی بین‌ماژولی باید با مستندات یا شواهد قابل مشاهدهٔ همان قابلیت بررسی شود.
مثال فرضی: آماده‌سازی بستهٔ آموزش داخلی
این مثال کاملاً فرضی است و نمایش قابلیت تأییدشدهٔ نرم‌افزار نیست. فرض کنید سازمانی می‌خواهد بستهٔ آموزش داخلی آماده کند. مسئول آموزش، خروجی نهایی را «محتوای تأییدشده و قابل استفاده برای کارکنان» تعریف می‌کند. گردآوری مطالب، بازبینی تخصصی و آماده‌سازی نسخهٔ نهایی، کارهای جداگانهٔ این سناریو هستند.
در سطح کار، مسئول و خروجی هر مرحله را مشخص کنید. در سطح پروژه، ترتیب انجام مراحل و نقاط تحویل را بنویسید. برای بررسی عملکرد، پیشاپیش تعیین کنید چه چیزی پذیرفتنی است؛ مثلاً پوشش سرفصل‌های توافق‌شده یا تأیید محتوای نهایی توسط مسئول تعیین‌شده.
اگر این سناریو به درخواست هزینه نیز نیاز داشت، آن را به‌عنوان نیاز جداگانه ثبت کنید. سپس بررسی کنید ماژول مربوط برای سازمان فعال است یا خیر و فرایند موردنظر چگونه پشتیبانی می‌شود. صرف وجود نام دو ماژول در معرفی محصول، برای اثبات ارتباط اجرایی میان آن‌ها کافی نیست.
چک‌لیست عملی پیش از انتخاب یا گسترش استفاده
- مسئلهٔ اصلی را در یک جمله بنویسید؛ مثلاً «مسئول تحویل هر خروجی مشخص نیست».
- یک نمونهٔ واقعی و بدون اطلاعات محرمانه برای بررسی آماده کنید.
- کارهای مستقل، مراحل پروژه و نیازهای ارزیابی عملکرد را جدا فهرست کنید.
- برای هر خروجی، مسئول، مهلت و معیار پذیرش پیشنهاد دهید.
- ماژول‌های لازم و وضعیت دسترسی سازمان به آن‌ها را مشخص کنید.
- قابلیت‌های موردنیاز را با نمایش یا مستندات قابل مشاهده بررسی کنید.
- برای هر نیاز بین‌ماژولی، مسیر موردانتظار را جداگانه بنویسید و تأیید بخواهید.
- پس از بررسی، نیازهای اثبات‌شده را از امکانات احتمالی تفکیک کنید.
اشتباه‌های رایج در صورت‌بندی مسئله
- یکی‌گرفتن بخش و کل: آغاز استفاده از مدیریت کار، دلیل کافی برای تعریف کل ERP به‌عنوان تسک‌منیجر نیست.
- فرض فعال‌بودن همهٔ ماژول‌ها: دامنهٔ معرفی محصول را جایگزین بررسی اشتراک، استقرار و مجوز دسترسی نکنید.
- انتقال قابلیت از یک مستند به محصول دیگر: نمونهٔ خارجی فقط شاهد همان نمونه است.
- شروع از فهرست امکانات: پیش از پرسیدن نام قابلیت‌ها، مسئله و خروجی موردانتظار را روشن کنید.
- فرض ارتباط خودکار: بدون شواهد مشخص، دربارهٔ انتقال داده یا اجرای گردش میان ماژول‌ها نتیجه‌گیری نکنید.
جمع‌بندی
مدیریت کار و پروژه را به‌عنوان بخشی از دامنهٔ ERP بررسی کنید و برای سنجش عملکرد، معیارها و شواهد موردنیاز خود را جداگانه تعریف کنید. در شناخت آسای آفیس نیز هویت ماژولار محصول، نیاز فعلی سازمان و امکانات واقعاً در دسترس را از هم تفکیک کنید. برای آشنایی با آسای آفیس، بررسی را از یک سناریوی روشن سازمانی آغاز کنید.