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