توسعه نرم‌افزار سازمانی

چرا کسب‌وکارها به نرم‌افزار اختصاصی نیاز دارند؟

وقتی فرایند واقعی کسب‌وکار شما در قالب هیچ نرم‌افزار آماده‌ای جا نمی‌شود

یک شرکت پخش را تصور کنید با سه انبار، صد و بیست کد کالا و شبکه‌ای از ویزیتورها. نرم‌افزار مالی و انبار دارد؛ لایسنس هم به‌روز است. اما وقتی وارد دفتر مرکزی می‌شوید این را می‌بینید:

    ▪      کارشناس فروش، تخصیص کالا به ویزیتورها را در یک فایل اکسل نگه می‌دارد، چون نرم‌افزار «مفهوم تخصیص» را ندارد.

    ▪      انباردار برای مرجوعی‌ها یک دفتر دستی دارد، چون گردش تأیید مرجوعی در سیستم سه مرحله دارد و در واقعیت پنج مرحله است.

    ▪      مدیر مالی هر ماه دو روز وقت می‌گذارد تا از سه گزارش مختلف، یک گزارش سودآوری به‌ازای مشتری بسازد.

هیچ‌کدام از این‌ها «خرابی نرم‌افزار» نیست. نرم‌افزار دقیقاً همان کاری را می‌کند که برایش ساخته شده. مسئله این است که این سازمان، فرایندی دارد که در قالب آن نرم‌افزار جا نمی‌شود؛ و چون جا نمی‌شود، سازمان یک سیستم سایه ساخته است: اکسل‌ها، دفترها، گروه‌های واتساپ و ذهن چند کارمند باتجربه.

نرم‌افزار اختصاصی، پاسخ به همین شکاف است — نه یک ژست فناورانه.

یک محصول آماده برای هزار مشتری نوشته می‌شود. طراح آن مجبور است مخرج مشترک هزار سازمان را پیدا کند و همان را پیاده کند. این یعنی نرم‌افزار آماده، فرایند متوسط صنعت شما را رمزگذاری می‌کند.

اما مزیت رقابتی هیچ کسب‌وکاری در «متوسط صنعت» نیست. مزیت شما دقیقاً در همان جاهایی است که متفاوت عمل می‌کنید: در نحوه‌ی قیمت‌گذاری پلکانی‌تان، در مدل پورسانت فروشندگانتان، در روش تسویه با تأمین‌کننده، در قاعده‌ای که فقط شما برای اولویت‌بندی سفارش‌ها دارید.

وقتی نرم‌افزار آماده می‌خرید، برای فرایندهای عمومی‌تان راه‌حل خوبی گرفته‌اید و برای فرایندهای متمایزتان یک محدودیت. و معمولاً همین فرایندهای متمایز هستند که پول درمی‌آورند.

اگر می‌خواهید بدون احساسات تصمیم بگیرید، این هفت نشانه را در سازمان خودتان بررسی کنید. هر کدام که برقرار باشد، یک امتیاز به سمت توسعه اختصاصی است.

۱. سیستم‌های سایه رشد کرده‌اند. کنار نرم‌افزار اصلی، فایل‌های اکسل، فرم‌های کاغذی یا گروه‌های پیام‌رسان وجود دارند که بدون آن‌ها کار پیش نمی‌رود. هر سیستم سایه، یک نیازمندی برآورده‌نشده است که خودش را نشان داده.

۲. یک داده را بیش از یک‌بار وارد می‌کنید. اطلاعاتی که از سیستم فروش در سیستم انبار دوباره ثبت می‌شود، یا فاکتوری که هم در نرم‌افزار مالی و هم در سامانه‌ی دیگری وارد می‌شود. دوباره‌کاری فقط وقت نمی‌برد؛ منبع اصلی مغایرت‌های پایان دوره است.

۳. فرایند را نرم‌افزار به شما دیکته می‌کند. جمله‌ی «سیستم اجازه نمی‌دهد» جای «سیاست ما این است» را گرفته. وقتی برای انجام کار درست باید سیستم را دور بزنید، نرم‌افزار از ابزار به مانع تبدیل شده است.

۴. گزارش‌های تصمیم‌ساز، دستی ساخته می‌شوند. اگر مدیرعامل برای دیدن سودآوری به‌ازای مشتری، شعبه یا محصول باید منتظر بماند تا کسی چند خروجی را در اکسل ترکیب کند، شما داده دارید ولی اطلاعات ندارید. و هر گزارش دستی، یک گزارش با احتمال خطاست.

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

۶. تغییرات قانونی و الزامات محلی دیر به دستتان می‌رسد. در فضای کسب‌وکار ایران، اتصال به سامانه‌های حاکمیتی (مانند سامانه مؤدیان)، تغییر قواعد مالیاتی و الزامات گزارش‌دهی مرتب به‌روزرسانی می‌خواهد. اگر برای هر تغییر باید در صف انتشار نسخه‌ی بعدی یک تأمین‌کننده بمانید، ریسک انطباق را برون‌سپاری کرده‌اید بدون آنکه کنترلی داشته باشید.

۷. دانش سازمانی در سیستم نیست، در ذهن آدم‌هاست. اگر با رفتن دو کارمند باتجربه بخشی از فرایند شما فلج می‌شود، آن فرایند هرگز واقعاً سیستمی نشده است. نرم‌افزارِ درست، قواعد کسب‌وکار را از حافظه‌ی افراد به دارایی سازمان منتقل می‌کند.

اشتباه رایج این است که فکر کنیم داریم «امکانات» می‌خریم. امکانات را می‌شود در هر محصولی خرید. چیزی که در توسعه اختصاصی می‌خرید، چهار چیز دیگر است:

۱. انطباق با فرایند، نه انطباق با فرم

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

۲. مالکیت داده و کد

داده‌ی شما در پایگاه داده‌ی خودتان است و می‌توانید بدون اجازه‌ی هیچ‌کس روی آن گزارش بگیرید، تحلیل کنید یا آن را به سامانه‌ی دیگری متصل کنید. مهاجرت از یک محصول بسته، معمولاً گران‌ترین بخش چرخه‌ی عمر آن است.

۳. سرعت تغییر

در محصول آماده، درخواست شما یکی از هزار درخواست است و باید با نقشه‌ی راه تأمین‌کننده رقابت کند. در سامانه‌ی اختصاصی، اولویت را کسب‌وکار شما تعیین می‌کند. وقتی بازار تغییر می‌کند، این تفاوت، تفاوتِ چند هفته با چند فصل است.

۴. تجربه‌ی کاربری متناسب با نقش

انباردار نباید فرم مالی ببیند و حسابدار نباید بین ده فیلد بی‌ربط دنبال دو فیلد کاربردی بگردد. صفحه‌ای که فقط همان کاری را نشان می‌دهد که کاربر باید انجام دهد، خطای انسانی و زمان آموزش را به‌شکل محسوسی کاهش می‌دهد.

مقایسه‌ی درست، مقایسه‌ی «قیمت خرید» با «هزینه‌ی ساخت» نیست؛ مقایسه‌ی هزینه‌ی کل مالکیت در یک بازه‌ی سه تا پنج ساله است. برای هر دو گزینه این اقلام را کنار هم بگذارید:

اقلام دو ردیفِ «دور زدن سیستم» و «دارایی باقی‌مانده» تقریباً همیشه از قلم می‌افتند، در حالی که معمولاً بزرگ‌ترین اعداد جدول‌اند.

هر مشاوری که بگوید توسعه اختصاصی همیشه پاسخ درست است، دارد چیزی می‌فروشد. در این چهار وضعیت، نروید:

    ▪      فرایند شما واقعاً استاندارد است. برای حقوق‌ودستمزد، حسابداری پایه یا اتوماسیون اداری عمومی، محصولات بالغ و ارزانی وجود دارد؛ ساختن دوباره‌ی آن‌ها اتلاف سرمایه است.

    ▪      مالک محصول در سازمان مشخص نیست. پروژه‌ای که یک تصمیم‌گیرنده‌ی مسئول ندارد، در مرحله‌ی تحلیل متوقف می‌شود؛ نه به‌خاطر فناوری، به‌خاطر بی‌تصمیمی.

    ▪      بودجه و افق زمانی واقعی ندارید. توسعه‌ی نیمه‌تمام از نخریدن بدتر است، چون هم پول رفته و هم فرایند به‌هم‌ریخته.

    ▪      هدف، «مدرن شدن» است نه حل یک مسئله. اگر نتوانید در یک جمله بگویید این سامانه قرار است کدام هزینه را حذف یا کدام درآمد را ممکن کند، هنوز آماده‌ی شروع نیستید.

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

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

۱. از یک برش عمودی شروع کنید، نه از همه‌ی ماژول‌ها. یک فرایند کامل و واقعی — مثلاً از ثبت سفارش تا صدور فاکتور — را انتخاب و تا انتها تحویل دهید. یک فرایند کاملِ در حال استفاده، از ده ماژول نیمه‌کاره ارزشمندتر است.

۲. قواعد کسب‌وکار را مکتوب کنید، پیش از آنکه کدی نوشته شود. قاعده‌هایی مانند «سند تأییدشده قابل ویرایش نیست» یا «تخفیف بالای ده درصد تأیید مدیر فروش می‌خواهد» باید شماره‌دار، صریح و مورد توافق باشند. هر ابهامی که در سند حل نشود، بعداً به‌شکل دوباره‌کاری در کد ظاهر می‌شود.

۳. معماری را ساده و ماژولار نگه دارید. جداسازی روشن منطق کسب‌وکار از لایه‌ی کاربر و تفکیک ماژول‌ها بر اساس دامنه، همان چیزی است که سه سال بعد اجازه می‌دهد سامانه بدون بازنویسی رشد کند. پیچیدگی معماری که توجیه کسب‌وکاری ندارد، بدهی فنی است، نه کیفیت.

۴. تحویل تدریجی و بازخورد کوتاه. هر دو تا چهار هفته باید چیزی قابل استفاده به دست کاربر واقعی برسد. پروژه‌ای که شش ماه در تاریکی توسعه داده می‌شود، در روز رونمایی با فرایندی روبه‌رو می‌شود که دیگر تغییر کرده است.

نرم‌افزار اختصاصی برای «داشتن سیستم» نیست؛ برای بستن شکاف میان کاری که کسب‌وکار شما واقعاً انجام می‌دهد و کاری که ابزارهایش اجازه می‌دهند انجام دهد. اگر این شکاف کوچک است، محصول آماده انتخاب عاقلانه‌ای است. اگر بزرگ است، شما همین حالا هم دارید هزینه‌اش را می‌پردازید — فقط در قالب ساعت‌های هدررفته، خطاهای انسانی و تصمیم‌های دیرهنگام، نه در قالب یک فاکتور.

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

اگر می‌خواهید بدانید وضعیت شما کدام‌یک از این دو حالت است، یک جلسه‌ی ارزیابی فرایند بگذارید. حتی اگر نتیجه این باشد که به توسعه اختصاصی نیاز ندارید، با تصویر روشن‌تری از فرایندتان بیرون می‌آیید.

متن کامل مقالات و نمونه‌کارها: garnetapp.ir

    ▪      نرم‌افزار آماده یا توسعه اختصاصی؛ کدام انتخاب بهتری است؟

    ▪      مراحل تحلیل، طراحی و توسعه یک نرم‌افزار سازمانی

    ▪      هزینه توسعه نرم‌افزار اختصاصی چگونه محاسبه می‌شود؟