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