تعریفِ رایجِ اتوماسیون اداری این است: «خودکارکردنِ کارهای کاغذی و تکراریِ سازمان برای حذفِ کاغذبازی». این تعریف غلط نیست، ولی چیزِ مهمی را جا می‌اندازد — و همان چیز است که تعیین می‌کند پروژه‌ی شما موفق می‌شود یا فقط کاغذ را دیجیتال می‌کند:

مسئله‌ی یک سازمانِ کند، سرعتِ انجامِ کار نیست؛ زمانِ انتظار بینِ کارهاست.

در بیشترِ فرایندهای اداری، مجموعِ زمانی که واقعاً کار انجام می‌شود چند دقیقه است و مجموعِ زمانی که درخواست روی میزِ یک نفر یا در صندوقِ یک نفر منتظر می‌ماند، چند روز. و نکته‌ی کلیدی این است که در سیستمِ کاغذی، این انتظار دیده نمی‌شود — هیچ‌کس نمی‌داند درخواست کجا و چند روز معطل مانده.

پس اولین و بزرگ‌ترین دستاوردِ اتوماسیون چیزِ دیگری است:

اندازه‌پذیر شدنِ تأخیر — نه حذفِ کاغذ.

و این ترتیب اهمیت دارد: بدونِ این اندازه‌گیری، شما نمی‌دانید گلوگاه کجاست و اتوماسیون را روی فرایندِ اشتباه پیاده می‌کنید.

مطالبی که در ادامه می خوانید:

قبل از هر تصمیمی، مطمئن شوید دربارهٔ کدام‌یک حرف می‌زنید — چون هر سه اسمِ مشترکی دارند و سه مسئله‌ی متفاوت را حل می‌کنند:

چه چیزی را حل می‌کندنشانه‌ی اینکه لازمش دارید
دبیرخانه و مکاتباتثبت، ارجاع، شماره و سابقه‌ی نامه«نامه گم شد» · «سابقه‌ی این مکاتبه کجاست؟»
گردشِ کار و فرم‌های داخلیمرخصی، درخواستِ خرید، تأییدها«درخواستم روی میزِ کیست؟»
مدیریتِ اسنادنسخه، دسترسی، بایگانی«کدام نسخه آخری است؟» · «چه کسی این را دیده؟»

⭐ و یک الگوی تکرارشونده: بیشترِ سازمان‌ها فکر می‌کنند اولی را می‌خواهند و در واقع دومی را لازم دارند. دلیلش هم قابلِ فهم است — «دبیرخانه‌ی الکترونیک» اسمِ آشناتری است، ولی چیزی که واقعاً کار را کند می‌کند نامه‌ی گم‌شده نیست؛ تأییدی است که معلوم نیست کجاست.

این مهم‌ترین چیزی است که قبل از شروعِ پروژه باید بدانید:

هر چیزی که در سیستمِ دستی مبهم بود، در سیستمِ دیجیتال اجباری می‌شود.

در سیستمِ کاغذی، اگر یکی از سه امضا لازم نبود، کسی آن را دور می‌زد و کار جلو می‌رفت. در سیستمِ دیجیتال همان سه امضا اجباری و قابلِ ردیابی می‌شوند — یعنی نتیجه‌ی اتوماسیون، فرایندی کندتر و رسمی‌تر از قبل است. این شایع‌ترین شکلِ شکستِ این پروژه‌ها است و همیشه هم با تعجب همراه است: «سیستم گرفتیم و کارها کندتر شد.»

پس قاعده‌ی اول:

قبل از خودکار کردن، حذف کنید.

و برای حذف کردن، یک آزمونِ ساده و بی‌رحم وجود دارد که روی هر مرحله‌ی تأیید اجرا می‌شود:

⭐⭐ «این تأییدکننده آخرین بار کِی «نه» گفت؟»

اگر جواب «هیچ‌وقت» یا «یادم نمی‌آید» باشد، آن مرحله در واقع تأیید نیست — اطلاع است. و این تفکیک یک نتیجه‌ی فنیِ فوری دارد:

اطلاع را می‌شود موازی فرستاد؛ فقط تأیید باید در صف بایستد.

یعنی همان فرایندی که پنج مرحله‌ی پشت‌سرهم داشت، ممکن است در واقع دو تأییدِ متوالی و سه اطلاعِ موازی باشد. و این بازچینی، بدونِ حذفِ هیچ مسئولیتی، زمانِ چرخه را کوتاه می‌کند.

نکته

یک نکته‌ی مکملِ همان آزمون: اگر تأییدکننده‌ای «نه» می‌گوید ولی همیشه به یک دلیلِ تکراری، آن «نه» یک تأیید نیست — یک قاعده است. و قاعده را می‌شود در فرم پیاده کرد: فیلدِ اجباری، سقفِ مبلغ، یا شرطی که اجازه‌ی ثبت نمی‌دهد. هر قاعده‌ای که به فرم منتقل شود، یک مرحله‌ی انسانی را کامل حذف می‌کند — و این ارزان‌ترین و پایدارترین نوعِ بهبود در این پروژه‌ها است.

این بخش به ضررِ فروشِ خودمان است و درست است. یک نشانه‌ی روشن وجود دارد که می‌گوید اتوماسیون فعلاً زود است:

اگر فرایندهای سازمانِ شما نوشته نشده‌اند، اتوماسیون زود است.

دلیلش عملی است، نه نظری: اولین کارِ هر پروژه‌ی اتوماسیون، نوشتنِ فرایند است — و آن کار را باید خودتان بکنید. اگر آن را به پیمانکار بسپارید، او ناچار است از چند مصاحبه حدس بزند فرایندِ شما چیست، و نتیجه‌اش این می‌شود:

پیمانکار حدسِ خودش را خودکار می‌کند — و شما ماه‌ها بعد، وقتی کاربران شروع به دور زدنِ سیستم کردند، متوجه می‌شوید.

نشانه‌ی آماده بودن هم ساده است: می‌توانید یک فرایند را در چند خط بنویسید، با «چه کسی، چه چیزی را، به چه کسی، در چه مدت». اگر می‌توانید، آماده‌اید. اگر برای هر فرایند سه نفر سه روایتِ متفاوت می‌دهند، اول همان اختلاف را حل کنید — چون سیستم آن اختلاف را حل نمی‌کند، فقط رسمی‌اش می‌کند.

روشِ درستِ سفارش دادنِ چنین پروژه‌ای — از مستندِ نیاز تا معیارِ پذیرش و بندِ خروج — در راهنمای سفارشِ نرم‌افزار اختصاصی آمده، و آماده بخرم یا اختصاصی بسازم بحثِ جداگانه‌ای است (راهنمای تصمیم).

پروژه‌های اتوماسیون به‌خاطرِ باگ شکست نمی‌خورند؛ به‌خاطرِ استفاده نشدن شکست می‌خورند. و علتش یک تفاوتِ ساختاری است که کمتر به آن اشاره می‌شود:

این تنها نرم‌افزاری است که کاربرش مجبور است از آن استفاده کند و انگیزه‌ای برایش ندارد.

کاربرِ یک فروشگاه خودش می‌آید چون چیزی می‌خواهد. کارمندِ شما نمی‌خواهد در سیستم فرم پر کند؛ او می‌خواهد کارش انجام شود. پس دو قاعده لازم است:

و یک توصیه‌ی اجرایی: با یک فرایند شروع کنید، نه با کلِ سازمان — و آن یکی را پرتکرارترین فرایند انتخاب کنید، نه سخت‌ترین. فرایندی که روزی چند بار انجام می‌شود، سریع‌تر عادت می‌سازد و سریع‌تر خطاهایش پیدا می‌شود.

چهار سیستمِ سازمانی مرتب با هم اشتباه گرفته می‌شوند. تفکیکشان ساده است:

و ERP نامِ دیگری برای «همه‌ی این‌ها در یک بسته» است. ⚠️ یک هشدارِ عملی: شروع از یک بسته‌ی یکپارچه برای سازمانی که فرایندهایش نوشته نشده، سریع‌ترین راهِ ساختنِ یک سیستمِ بزرگِ استفاده‌نشده است. ترتیبِ کم‌ریسک‌تر این است که از یک فرایندِ مشخص شروع کنید و بعد وصل کنید — و اگر مجموعه‌ی شما چند شرکت است، تصمیمِ معماری خودش بحثِ جداگانه‌ای دارد (سایت شرکتی یا هلدینگ).

یک سؤالِ به‌ظاهر فرعی که در عمل تعیین‌کننده است: تأییدها روی موبایل انجام می‌شوند یا روی رایانه؟

جوابش تقریباً همیشه «موبایل» است — چون گلوگاهِ فرایند اغلب مدیری است که سرِ میزش نیست. و اگر سیستم روی موبایل غیرقابلِ استفاده باشد، همان تأخیری که می‌خواستید حذف کنید سرِ جایش می‌ماند، فقط این بار دیجیتال است. پس تأییدِ موبایلی جزوِ حداقل‌ها است، نه یک ویژگیِ لوکس — و انتخابِ بینِ اپ و وب برای این کار در اندروید، iOS یا PWA باز شده.

حواستان باشد

یک خرابیِ رایج که سیستم را از کار می‌اندازد بی‌آنکه خراب باشد: اعلانِ زیاد. سیستمی که برای هر رویداد به همه ایمیل و پیام می‌فرستد، پس از چند هفته به یک نویز تبدیل می‌شود و کاربران یاد می‌گیرند اعلان‌هایش را نبینند — و از آن لحظه، همان تأییدهای واقعی هم دیده نمی‌شوند. قاعده‌ی درست: اعلان فقط برای چیزی که از گیرنده کاری می‌خواهد؛ بقیه در فهرستِ کارهای خودش بماند تا وقتی سراغش رفت ببیند.

سه عدد، و ترتیبِ اهمیتشان مهم است:

و برآوردِ هزینه و اینکه چرا برآوردهای این جنس پروژه می‌لنگند، در هزینه‌ی نرم‌افزار اختصاصی آمده.

سه چیز را ببرید. اول: مسئله‌ی سازمانِ کند سرعتِ کار نیست، زمانِ انتظار بینِ کارهاست — و انتظار در سیستمِ کاغذی دیده نمی‌شود؛ پس اولین دستاوردِ اتوماسیون اندازه‌پذیر شدنِ تأخیر است، نه حذفِ کاغذ. دوم: اتوماسیون یک آینه است و هر ابهامِ سیستمِ دستی را اجباری می‌کند — پس قبل از خودکار کردن حذف کنید، و آزمونش این است: این تأییدکننده آخرین بار کِی «نه» گفت؟ سوم: تنها ریسکِ واقعی پذیرشِ کاربر است؛ مسیرِ قدیمی را باید بست، و هر مرحله باید برای کاربرِ خودش هم یک چیزی داشته باشد.

اگر سازمانتان درگیرِ فرایندهای دستیِ کند است و فرایندها را نوشته‌اید: سیستم اتوماسیون اداری اختصاصی.

یک فرایندِ کندتان را در چند خط بگویید — می‌گوییم کدام مرحله‌هایش تأییدِ واقعی است و کدام‌ها را می‌شود موازی یا حذف کرد.برآورد هزینه و زمان را در یک تماس کوتاه می‌گیرید.