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