طراحی سامانهی اختصاصی تحت وب یعنی ساختن نرمافزاری که دقیقاً برای کارهای روزمره‌ی کسبوکار شما نوشته میشود و کارکنان، مشتریان یا نمایندگانتان آن را با مرورگر و از هر جایی باز میکنند، بدون نصب برنامه روی هر کامپیوتر. این سامانه میتواند سفارش‌ها، مشتریان، نوبت‌ها، انبار یا گزارش‌های مدیریتی را در یک جا جمع کند، به پیامک، درگاه پرداخت و نرمافزار حسابداری وصل شود و به هر نفر فقط همان بخشی را نشان دهد که اجازه دارد ببیند. نرمافزار سفارشی وقتی ارزش هزینهاش را دارد که فرایند کاری شما با نرمافزارهای آماده جور درنمی‌آید، داده‌ها بین چند ابزار و فایل اکسل پخش شده، یا رشد کسبوکار به کاری بسته است که هیچ محصول آماده‌ای درست انجامش نمی‌دهد. اگر نیازتان استاندارد است، نرمافزار آماده ارزان‌تر و سریع‌تر است.
این راهنما برای صاحب کسبوکار یا مدیری نوشته شده که می‌خواهد پیش از سفارش دادن یک سامانه، بداند دقیقاً چه چیزی می‌خرد، چه چیزهایی را باید از قبل روشن کند، و چطور مطمئن شود که بعد از تحویل، صاحب واقعی نرمافزار خودش است. درباره‌ی هزینه و عوامل قیمت به‌طور مفصل در راهنمای هزینهی طراحی نرمافزار سفارشی نوشته‌ایم؛ این‌جا تمرکز روی تصمیم گرفتن، آماده‌سازی و اجرای درست پروژه است.
سامانهی تحت وب چیست و چه فرقی با سایت دارد؟
سامانهی تحت وب نرمافزاری است که در مرورگر اجرا میشود و کارش انجام دادن یک فرایند است، در حالی که سایت بیشتر برای معرفی و اطلاعرسانی ساخته میشود. سایت شرکت را هر کسی باز میکند و همه یک چیز میبینند: خدمات، نمونهکارها، راه تماس. سامانه را کاربرانی باز میکنند که وارد حساب خودشان میشوند و هر کدام بسته به نقششان چیز متفاوتی میبینند و کار متفاوتی انجام میدهند: کارشناس فروش سفارش ثبت میکند، انباردار خروج کالا را تأیید میکند و مدیر گزارش فروش ماه را میبیند.
از نظر فنی هم تفاوت در جایی است که پیچیدگی قرار دارد. در سایت، بیشترِ کار صرف ظاهر، محتوا و سئو میشود. در سامانه، بیشترِ کار صرف منطق کسبوکار میشود: قاعده‌هایی مثل اینکه سفارش بالای یک سقف مشخص باید به تأیید مدیر برسد، تخفیف نماینده‌ی درجه‌یک با نماینده‌ی تازه فرق دارد، یا موجودی کالا هنگام ثبت پیش‌فاکتور رزرو شود اما تا پرداخت از انبار کم نشود. همین قاعده‌ها هستند که سامانهی شما را از سامانهی هر کسبوکار دیگری متمایز میکنند.
مزیت تحت وب بودن هم روشن است: نصب و به‌روزرسانی روی تک‌تک دستگاه‌ها لازم نیست، از دفتر، خانه یا گوشی همراه قابل استفاده است، و اطلاعات در یک جای مرکزی نگه داشته میشود، نه روی کامپیوتر یک کارمند که ممکن است خراب شود یا آن کارمند برود.
نرمافزار سفارشی چه فرقی با نرمافزار آماده دارد؟
نرمافزار آماده برای نیاز مشترک هزاران کسبوکار ساخته شده و شما خودتان را با آن تطبیق میدهید، اما نرمافزار سفارشی برای فرایند شما ساخته میشود و خودش را با شما تطبیق میدهد. نرمافزار آماده دو شکل رایج دارد: نسخهی اشتراکی آنلاین که ماهانه یا سالانه برایش پول میدهید و روی سرور فروشنده اجرا میشود، و نسخهی قفلی یا جعبهای که یک بار میخرید و روی سیستم خودتان نصب میکنید، مثل بسیاری از نرمافزارهای حسابداری و انبارداری رایج.
تفاوت‌ها را در چند محور میشود خلاصه کرد:
- نرمافزار آماده از روز اول آماده‌ی کار است، اما سامانهی سفارشی چند هفته تا چند ماه زمان ساخت می‌خواهد.
- در نرمافزار آماده هزینهی شروع کم است و هزینهی اشتراک یا ارتقا ادامه دارد؛ در سفارشی هزینهی ساخت در ابتدا سنگین‌تر است و بعد از آن هزینهی پشتیبانی و توسعه میماند.
- در نرمافزار آماده فقط امکاناتی را دارید که فروشنده تصمیم گرفته بسازد؛ در سفارشی هر امکانی که لازم باشد قابل اضافه شدن است.
- در نسخه‌های اشتراکی، داده‌ها روی سرور فروشنده است و قواعد نگهداری و خروجی گرفتن از آن را فروشنده تعیین میکند؛ در سفارشی، اگر قرارداد درست بسته شود، داده و کد هر دو مال شماست.
- اتصال نرمافزار آماده به ابزارهای دیگر به این بستگی دارد که فروشنده چنین امکانی گذاشته باشد؛ در سفارشی اتصال‌ها از ابتدا طبق نیاز شما طراحی میشوند.
چه وقت نرمافزار آماده انتخاب بهتری است؟
وقتی فرایند شما استاندارد است و یک محصول آماده تقریباً همهی نیازتان را پوشش میدهد، نرمافزار آماده تقریباً همیشه انتخاب عاقلانهتری است. حسابداری رسمی، حقوق و دستمزد و ایمیل سازمانی نمونههای روشنش هستند: این کارها تقریباً در همهی کسبوکارها یکسان انجام میشود، قواعدشان را مرجع بیرونی تعیین میکند و محصولات جاافتادهای برایشان وجود دارد که سالها آزموده شدهاند. ساختن دوبارهی آنها از صفر معمولاً پول و زمان را هدر میدهد.
چند نشانه‌ی دیگر هم می‌گوید هنوز وقت سامانهی سفارشی نرسیده است:
- کسبوکار تازه شروع شده و هنوز فرایندهایش ثابت نشده‌اند؛ نرمافزاری که امروز سفارش دهید، شاید شش ماه بعد با روش کار جدیدتان جور نباشد.
- مشکل اصلی نبودن نظم در کار است، نه نبودن ابزار؛ نرمافزار بی‌نظمی را از بین نمی‌برد، فقط آن را دیجیتال میکند.
- کسی در سازمان نیست که وقت بگذارد، نیازها را توضیح دهد و نسخه‌های آزمایشی را امتحان کند.
- بودجه فقط برای ساخت کافی است و برای نگهداری و پشتیبانی سال‌های بعد چیزی کنار گذاشته نشده است.
در چنین وضعی، شروع با ابزارهای آماده و حتی یک اکسل منظم، بهترین آمادگی برای سامانهی سفارشیِ آینده است، چون نشان میدهد دقیقاً کجای کار گیر دارد.
چه وقت سامانهی سفارشی ارزش هزینهاش را دارد؟
سامانهی سفارشی وقتی میارزد که روش کار شما بخشی از مزیت رقابتیتان است، یا وقتی هزینهی پنهان کار با ابزارهای پراکنده از هزینهی ساخت بیشتر شده است. این هزینهی پنهان معمولاً در صورتحسابها دیده نمیشود: ساعتهایی که کارمندان صرف وارد کردن یک اطلاعات در سه جای مختلف میکنند، سفارشهایی که بین پیامرسان و دفتر و اکسل گم میشوند، گزارشی که مدیر هر هفته منتظرش میماند تا کسی دستی جمعش کند، و تصمیمهایی که چون دادهی درست در دسترس نبوده، با حدس گرفته شدهاند.
نشانه‌های رایج اینکه کسبوکار به این نقطه رسیده:
- چند نرمافزار و فایل اکسل دارید که هیچ‌کدام با دیگری حرف نمی‌زند و کسی باید اطلاعات را دستی بینشان جابه‌جا کند.
- با اضافه شدن مشتری یا شعبه، مجبورید نیرو اضافه کنید فقط برای اینکه کارهای تکراری ثبت و پیگیری انجام شود.
- نرمافزار آماده‌ای که دارید را آن‌قدر با راه‌حل‌های دور زدنی تطبیق داده‌اید که فقط یکی دو نفر در شرکت بلدند با آن کار کنند.
- مشتری یا نماینده‌ی شما باید برای کاری ساده، مثل دیدن وضعیت سفارش، تلفن بزند چون جایی برای دیدنش ندارد.
- فرایندی دارید که در بازار شما کمتر کسی مثلش را دارد و نمی‌خواهید آن را به قالب یک محصول عمومی دربیاورید.
نمونههای رایج سامانهی اختصاصی برای کسبوکارها کداماند؟
رایجترین سامانههایی که کسبوکارها سفارش میدهند، مدیریت سفارش، مدیریت مشتری، نوبتدهی، انبار، پرتال نمایندگان و داشبورد مدیریتی است. اینها را با زبان کار روزمره توضیح میدهیم، نه با اصطلاحات فنی:
- سامانهی مدیریت سفارش: هر سفارش از لحظه‌ی ثبت تا تحویل یک پرونده دارد، معلوم است الان دست کیست، کدام مرحله عقب افتاده و مشتری در هر مرحله پیامک خودکار می‌گیرد.
- سامانهی مدیریت ارتباط با مشتری (CRM): همهی تماس‌ها، پیشفاکتورها، خریدها و پیگیری‌های هر مشتری در یک صفحه جمع است و اگر کارشناس فروش برود، سابقه‌ی مشتری با او نمی‌رود.
- سامانهی نوبتدهی و رزرو: مشتری خودش زمان خالی را میبیند و رزرو میکند، بیعانه می‌پردازد و یادآوری می‌گیرد، و شما برنامه‌ی هر کارمند یا اتاق را یک‌جا می‌بینید.
- سامانهی انبار: ورود و خروج کالا، موجودی چند انبار، هشدار کم شدن موجودی و ردیابی اینکه هر کالا به کدام سفارش رفته است.
- پرتال نمایندگان و همکاران فروش: نماینده با حساب خودش قیمت مخصوص خودش را میبیند، سفارش ثبت میکند، مانده‌حسابش را میبیند و فاکتورهایش را دانلود میکند، بدون اینکه هر بار با دفتر مرکزی تماس بگیرد.
- داشبورد مدیریتی داخلی: عددهایی که مدیر هر روز لازم دارد، مثل فروش، سفارش‌های معوق یا عملکرد شعبه‌ها، بدون منتظر ماندن برای گزارش دستی جلوی چشمش است.
در عمل بسیاری از پروژه‌ها ترکیبی از این‌هاست. سامانهای که با مدیریت سفارش شروع میشود، معمولاً بعداً بخش مشتری، انبار و پرتال نماینده هم پیدا میکند. برای همین بهتر است از ابتدا طوری طراحی شود که این رشد را تحمل کند.
پیش از گرفتن قیمت، نیازمندیها را چطور بنویسیم؟
نیازمندیها را با زبان کار خودتان بنویسید، نه با زبان فنی: چه کسانی از سامانه استفاده میکنند، هر کدام چه کاری انجام میدهند، کار از کجا شروع و به کجا ختم میشود، چه گزارشهایی میخواهید و سامانه باید به چه چیزهایی وصل شود. سندی که این پنج سؤال را جواب دهد، از هر فهرست بلند امکانات مفیدتر است. بدون آن، هر شرکتی برداشت خودش را از پروژه قیمت میدهد و پیشفاکتورها اصلاً قابل مقایسه نیستند.
کاربران و نقش‌ها را این‌طور فهرست کنید:
- برای هر گروه کاربر یک نام بگذارید، مثلاً مدیر، کارشناس فروش، انباردار، حسابدار، نماینده و مشتری، و تعداد تقریبی هر گروه را بنویسید.
- برای هر نقش بنویسید چه چیزهایی را باید ببیند، چه چیزهایی را میتواند تغییر دهد و چه چیزهایی را به هیچ وجه نباید ببیند.
- مشخص کنید کدام کاربران داخل سازمان‌اند و کدام بیرون، چون کاربران بیرونی مثل مشتری و نماینده معمولاً به ظاهر سادهتر و امنیت دقیق‌تری نیاز دارند.
گردش کار را مرحله‌به‌مرحله توصیف کنید:
- یک کار واقعی، مثل یک سفارش، را از اولین تماس مشتری تا تسویه‌ی نهایی قدم‌به‌قدم بنویسید و جلوی هر قدم بنویسید چه کسی انجامش میدهد.
- جاهایی را که تأیید لازم دارد، مثل تخفیف ویژه یا خرید بالای یک سقف، جداگانه علامت بزنید.
- استثناها را فراموش نکنید: سفارش لغوشده، کالای مرجوعی، پرداخت ناقص؛ معمولاً همین موارد است که بیشترین زمان ساخت را می‌گیرد.
- اگر الان این کار با فرم کاغذی یا اکسل انجام میشود، نمونهی همان فرم یا فایل را ضمیمه کنید؛ برای تیم سازنده از هر توضیحی گویاتر است.
گزارش‌ها را بر اساس تصمیمی که می‌گیرید بنویسید. به‌جای «گزارش فروش»، بنویسید «می‌خواهم هر صبح ببینم دیروز هر کارشناس چند سفارش ثبت کرده و چندتایش هنوز پرداخت نشده». این جمله برای سازنده روشن میکند چه داده‌ای کجا باید ثبت شود تا آن گزارش ممکن شود.
اتصال‌ها را هم کامل فهرست کنید:
- پیامک: کدام پیام‌ها خودکار ارسال شوند، به چه کسی و در چه لحظه‌ای، و از کدام سامانهی پیامک استفاده میکنید.
- درگاه پرداخت: آیا مشتری داخل سامانه پرداخت میکند، پرداخت اقساطی یا بیعانه دارید، و درگاه بانکی شما کدام است.
- حسابداری: نرمافزار حسابداری فعلی‌تان چیست و آیا فاکتورها باید خودکار به آن منتقل شوند یا خروجی اکسل کافی است.
- نرمافزارهای موجود: سایت فروشگاهی، نرمافزار انبار یا هر ابزار دیگری که سامانه باید با آن داده رد و بدل کند.
اتصال سامانه‌ها به یکدیگر معمولاً از راه API انجام میشود؛ اگر این اصطلاح برایتان ناآشناست، راهنمای ساده‌ی API توضیح میدهد چیست و چرا پیش از قرارداد باید بپرسید نرمافزارهای فعلی‌تان API دارند یا نه. نرمافزاری که هیچ راه خروجی برای داده ندارد، میتواند بخش قابل‌توجهی از برنامه‌ی پروژه را تغییر دهد.
در آخر، فهرست را اولویت‌بندی کنید: چه چیزهایی بدون آنها سامانه به کار نمی‌آید و چه چیزهایی «خوب است داشته باشیم». این تفکیک در مرحله‌ی نسخهی اول، که پایین‌تر توضیح داده‌ایم، کلیدی است.
مراحل ساخت یک سامانهی اختصاصی چیست؟
یک سامانهی اختصاصی معمولاً در چهار مرحله ساخته میشود: کشف و تحلیل نیاز، نمونهی اولیه، نسخهی اول قابل استفاده (MVP) و بعد چرخههای پیاپی بهبود و توسعه. این ترتیب برای این است که اشتباهها در ارزانترین مرحله پیدا شوند. تغییر یک صفحه در نمونهی اولیه چند ساعت کار است؛ همان تغییر بعد از برنامهنویسی کامل ممکن است چند روز طول بکشد و بخشهای دیگر را هم به هم بریزد.
- کشف و تحلیل: تیم سازنده با شما و کاربران اصلی جلسه می‌گذارد، فرایندها را از نزدیک میبیند و نیازها را به سندی تبدیل میکند که هر دو طرف آن را تأیید میکنند. این مرحله بسته به اندازه‌ی کار معمولاً یک تا چند هفته طول می‌کشد، چون باید با چند نفر در چند نقش صحبت شود.
- نمونهی اولیه: صفحه‌های اصلی سامانه به شکل طرح قابل کلیک ساخته میشوند تا کاربران واقعی پیش از نوشته شدن کد، ببینند کار با آن چطور خواهد بود و بگویند کجا با روش کارشان نمی‌خواند.
- نسخهی اول (MVP): فقط بخش‌هایی ساخته میشوند که بدون آنها سامانه به کار نمی‌آید، و سامانه با دادهی واقعی و تعداد محدودی کاربر به کار می‌افتد. هدف این است که زودتر از سامانه استفاده شود و بازخورد واقعی برسد، نه اینکه ماه‌ها روی امکاناتی کار شود که شاید کسی از آنها استفاده نکند.
- چرخههای بهبود: بعد از راه‌اندازی، کار در دوره‌های کوتاه ادامه پیدا میکند؛ در هر دوره چند امکان تازه یا اصلاح بر اساس استفاده‌ی واقعی اضافه میشود و شما پیش از شروع هر دوره اولویت‌ها را تعیین میکنید.
زمان کل پروژه به تعداد نقش‌ها، پیچیدگی گردش کار و تعداد اتصال‌ها بستگی دارد. یک سامانهی تک‌فرایندی با چند نقش ممکن است ظرف دو تا سه ماه به نسخهی اول برسد، و سامانهای که چند بخش سازمان را به هم وصل میکند و به چند نرمافزار بیرونی متصل است، معمولاً چند ماه بیشتر می‌خواهد. زمان پاسخ‌گویی خود شما هم مهم است: پروژه‌هایی که در آنها تأیید هر مرحله هفته‌ها منتظر میماند، به همان اندازه طولانی میشوند.
اشتباه رایج این است که کارفرما همهی امکانات را در نسخهی اول بخواهد. نتیجه‌اش پروژه‌ای است که دیرتر از برنامه تحویل میشود و بخشی از امکاناتش هرگز استفاده نمیشود. نسخهی اول کوچک و درست، تقریباً همیشه از نسخهی اول بزرگ و ناقص بهتر است.
امنیت و سطوح دسترسی در سامانهی تحت وب چطور تأمین میشود؟
امنیت سامانهی تحت وب از سه لایه ساخته میشود: اینکه فقط افراد مجاز وارد شوند، اینکه هر کس فقط به همان بخشی دسترسی داشته باشد که برایش تعریف شده، و اینکه هر کار مهم ثبت شود تا معلوم باشد چه کسی، چه زمانی، چه کرد. سامانهای که اطلاعات مشتریان، قیمتهای خرید یا حساب نمایندگان را نگه میدارد، اگر یکی از این لایهها را نداشته باشد، دیر یا زود دردسرساز میشود.
چیزهایی که باید از سازنده بپرسید یا در قرارداد ببینید:
- سطوح دسترسی باید بر اساس نقش تعریف شوند و مدیر بتواند بدون برنامه‌نویس، نقش کاربران را تغییر دهد یا حساب کارمندی را که رفته غیرفعال کند.
- برای حساب‌های حساس مثل مدیر و حسابدار، ورود دومرحله‌ای با کد پیامکی یا برنامه‌ی تولید رمز یکبارمصرف امکان‌پذیر باشد.
- تغییرات مهم، مثل ویرایش قیمت، حذف سفارش یا تغییر موجودی، در گزارش رویدادها با نام کاربر و زمان ثبت شوند.
- ارتباط با سامانه از طریق HTTPS رمزگذاری شود و رمزهای عبور به شکل قابل بازگشت در پایگاه داده ذخیره نشوند.
- کد در برابر حمله‌های رایج وب، مثل تزریق کد به پایگاه داده و جعل درخواست، محافظت شده باشد؛ فریم‌ورک‌های جاافتاده بخش زیادی از این محافظت را به‌طور پیش‌فرض دارند، به شرطی که درست استفاده شوند.
به همین دلیل انتخاب فناوری هم بی‌اهمیت نیست. ما سامانه‌های اختصاصی را بیشتر با لاراول می‌سازیم، چون ابزارهای امنیتی، مدیریت دسترسی و ساختار منظم کد را آماده دارد؛ دلایل این انتخاب و محدودیت‌هایش در مقاله‌ی لاراول برای سامانه‌های سازمانی آمده است.
نسخهی پشتیبان سامانه چطور باید گرفته شود؟
نسخهی پشتیبان باید خودکار، روزانه یا حتی چند بار در روز، و در جایی جدا از سرور اصلی گرفته شود، و هر چند وقت یکبار بازگردانی آن واقعاً آزمایش شود. پشتیبانی که روی همان سروری نگه داشته میشود که سامانه روی آن است، با خراب شدن یا هک شدن سرور همراه خودش از بین میرود. و پشتیبانی که هیچوقت بازگردانیاش آزمایش نشده، فقط ظاهراً پشتیبان است؛ ممکن است روزی که لازمش دارید، معلوم شود ناقص یا خراب بوده است.
- هم پایگاه داده و هم فایل‌های بارگذاری‌شده، مثل فاکتورها و عکس‌ها، در برنامه‌ی پشتیبان باشند.
- چند نسخهی قدیمی‌تر هم نگه داشته شود، نه فقط آخرین نسخه، تا اگر خطایی چند روز دیده نشد، بتوان به پیش از آن برگشت.
- مشخص باشد پشتیبان‌ها کجا نگه داشته میشوند، چه کسی به آنها دسترسی دارد و شما چطور می‌توانید یک نسخه از آنها را برای خودتان بگیرید.
- در قرارداد پشتیبانی بیاید که اگر سامانه از کار افتاد، بازگردانی از آخرین پشتیبان با چه سرعتی انجام میشود.
سامانه را روی سرور اختصاصی خودمان نصب کنیم یا روی سرور ابری؟
برای بیشتر کسبوکارها سرور ابری یا مجازی اجارهای انتخاب سادهتر و مطمئنتری است، و سرور فیزیکی در محل خود سازمان فقط وقتی معنی دارد که الزام مشخصی برای نگهداری داده در داخل سازمان دارید و کسی را برای نگهداری آن در اختیار دارید. سرور داخلی یعنی برق، اینترنت، سختافزار، بهروزرسانیهای امنیتی و پشتیبانگیری همه با خود شماست، و یک خرابی دیسک یا قطعی طولانی اینترنت دفتر میتواند کل سامانه را برای کاربران بیرونی، مثل نمایندگان، از دسترس خارج کند.
چند نکته در انتخاب محل میزبانی:
- اگر بیشتر کاربران در ایران هستند، سرور داخل کشور معمولاً پایداری و سرعت بهتری برای آنها دارد و در قطعی‌های ارتباط بین‌المللی هم در دسترس میماند.
- اگر سامانه باید به سرویس‌های خارجی وصل شود یا کاربرانی بیرون از ایران دارد، ممکن است به ترکیبی از سرور داخلی و خارجی نیاز باشد که باید از ابتدا در طراحی دیده شود.
- حساب سرور به نام خود شما یا شرکتتان باشد، نه به نام شرکت سازنده، تا اگر روزی همکاری تمام شد، زیرساخت در اختیار خودتان بماند.
- منابع سرور را بر اساس تعداد کاربر همزمان و حجم داده انتخاب کنید و برای رشد جا بگذارید؛ ارتقای سرور ابری معمولاً ساده است، اما بهتر است از پیش معلوم باشد چه کسی آن را زیر نظر دارد.
اگر با تفاوت انواع سرور و میزبانی آشنا نیستید، راهنمای هاست و دامنه مفاهیم پایه را توضیح میدهد.
مالکیت داده و کد منبع سامانه با چه کسی است؟
مالکیت داده و کد منبع با کسی است که قرارداد مشخص میکند، نه لزوماً با کسی که پول داده است؛ پس باید پیش از امضا، صریحاً در قرارداد بیاید که کد منبع کامل، پایگاه داده و همهی مستندات پس از تسویه به شما تحویل داده میشود. اگر این بند در قرارداد نباشد، ممکن است بعدها متوجه شوید سامانهای که هزینهاش را داده‌اید فقط روی سرور شرکت سازنده اجرا میشود و هر تغییر کوچکی باید از همان شرکت و با قیمت همان شرکت خریده شود. به این وضعیت قفل شدن به فروشنده می‌گویند و یکی از پرهزینه‌ترین اشتباه‌های پروژه‌های نرمافزاری است.
برای اینکه قفل نشوید، این موارد را بخواهید:
- کد منبع در یک مخزن کد (مثل Git) نگه داشته شود که شما هم به آن دسترسی دارید، تا تاریخچه‌ی همهی تغییرات ثبت باشد و هر لحظه بتوانید نسخهی کامل را بگیرید.
- سامانه با فناوری رایج و شناخته‌شده ساخته شود، نه با ابزاری که فقط همان شرکت بلد است، تا برنامه‌نویس دیگری هم بتواند کار را ادامه دهد.
- مستندات فنی تحویل داده شود: ساختار پایگاه داده، نحوه‌ی نصب روی سرور جدید، فهرست اتصال‌ها و کلیدهای لازم و توضیح بخشهای اصلی کد.
- راهنمای کاربری برای هر نقش نوشته شود تا آموزش کارمندان جدید به حافظه‌ی یک نفر وابسته نباشد.
- همهی حساب‌های جانبی، از سرور و دامنه تا پنل پیامک و درگاه پرداخت، به نام خود شما باشند و رمزهایشان در اختیار خودتان.
- امکان خروجی گرفتن از داده‌ها در قالب استاندارد، مثل اکسل، در خود سامانه وجود داشته باشد.
بعضی شرکت‌ها از یک هسته‌ی آماده‌ی خودشان استفاده میکنند و فقط حق استفاده میدهند، نه مالکیت. این لزوماً بد نیست و گاهی هزینه را پایین می‌آورد، اما باید پیش از قرارداد بدانید کدام را میخرید و نتیجه‌اش برای آینده چیست.
بعد از تحویل سامانه، پشتیبانی و توسعه چطور ادامه پیدا میکند؟
بعد از تحویل، سامانه به دو نوع کار مداوم نیاز دارد: پشتیبانی، یعنی رفع اشکال، بهروزرسانیهای امنیتی، نظارت بر سرور و پشتیبانگیری، و توسعه، یعنی اضافه کردن امکانات تازه‌ای که با استفاده‌ی واقعی معلوم میشود لازم است. سامانهای که بعد از تحویل رها شود، کم‌کم از نسخه‌های جدید زبان برنامهنویسی و سیستم‌عامل عقب میماند و هر چه این فاصله بیشتر شود، به‌روزرسانی‌اش پرهزینه‌تر و خطرناک‌تر میشود.
در اغلب پروژه‌ها، چند هفته‌ی اول پس از راه‌اندازی شلوغ‌ترین دوره است: کاربران با موقعیت‌هایی روبه‌رو میشوند که در تحلیل دیده نشده بود و درخواست‌های اصلاح زیاد است. به همین دلیل همهی پکیج‌های نرمافزاری ما سه ماه پشتیبانی رایگان دارند و بعد از آن پشتیبانی ماهانه ادامه پیدا میکند.
پیش از قرارداد پشتیبانی، این موارد را روشن کنید:
- زمان پاسخ به مشکل‌ها بر اساس شدتشان چقدر است؛ از کار افتادن کامل سامانه با یک اشکال ظاهری در یک گزارش فرق دارد.
- مرز بین رفع اشکال، که جزو پشتیبانی است، و امکان تازه، که جزو توسعه است، از پیش تعریف شده باشد تا سر هر درخواست بحث پیش نیاید.
- درخواست‌ها از چه مسیری ثبت میشوند و چطور می‌توانید وضعیت هر کدام را دنبال کنید.
- درخواست‌های توسعه چطور قیمت‌گذاری میشوند: بسته‌ی ساعتی، دوره‌های ثابت یا قیمت جداگانه برای هر کار.
تفاوت پکیج‌های نرمافزار سفارشی کیبووب چیست؟
پکیج‌های نرمافزار سفارشی کیبووب سه سطح دارند که بر اساس اندازه و پیچیدگی سامانه از هم جدا میشوند: سامانهی تحت‌وب از ۱۵۰ میلیون تومان، سامانهی سازمانی از ۲۵۰ میلیون تومان و پروژه‌های سفارشی بزرگ از ۴۰۰ میلیون تومان. این ارقام نقطه‌ی شروع هستند و رقم نهایی بعد از جلسه‌ی تحلیل، بر اساس تعداد نقش‌ها، پیچیدگی گردش کار، گزارش‌ها و اتصال‌ها در پیش‌فاکتور نوشته میشود.
- سامانهی تحت‌وب (از ۱۵۰): برای کسب‌وکاری که یک فرایند اصلی را می‌خواهد سامانه‌دار کند، مثل مدیریت سفارش یا نوبتدهی. شامل پنل مدیریت کامل، سطوح دسترسی کاربران و ساخت با لاراول است، و مناسب جایی است که کاربران محدود و فرایند روشن است.
- سامانهی سازمانی (از ۲۵۰): برای سازمان متوسطی که چند بخشش باید در یک سامانه به هم وصل شوند. ماژول‌های اختصاصی هر بخش، داشبورد و گزارش‌گیری مدیریتی، اتصال به سامانه‌های دیگر از طریق API و امنیت و پشتیبانگیری در سطح سازمانی را دارد و بعد از تحویل، توسعه‌ی مستمر هم در برنامه است.
- سفارشی (از ۴۰۰): برای پروژه‌های بزرگ و خاص، مثل سامانهای با کاربران زیاد، چند شعبه یا شبکه‌ی گسترده‌ی نمایندگان. معماری اختصاصی مقیاس‌پذیر، تیم توسعه‌ی اختصاصی، طراحی زیرساخت و استقرار، و قرارداد بلندمدت با تعهد سطح خدمت سازمانی دارد.
هر سه سطح سه ماه پشتیبانی رایگان دارند. اگر مطمئن نیستید پروژه‌تان در کدام سطح قرار می‌گیرد، معمولاً تعداد نقش‌ها و تعداد نرم‌افزارهایی که سامانه باید به آنها وصل شود بهترین سرنخ است. جزئیات بیشتر هر سطح در صفحه‌ی طراحی نرمافزار سفارشی آمده و اگر میخواهید بدانید چه چیزهایی قیمت را بالا یا پایین می‌برد، راهنمای هزینهی نرمافزار سفارشی عوامل را یکی‌یکی توضیح داده است.
هنگام انتخاب شرکت سازنده‌ی سامانه چه بپرسیم؟
مهم‌ترین چیزی که باید از شرکت سازنده بپرسید این است که پروژه را چطور تحلیل میکند، نه اینکه چقدر سریع تحویل میدهد. شرکتی که بدون هیچ سؤالی درباره‌ی فرایند شما و فقط با یک تماس تلفنی قیمت قطعی میدهد، یا پروژه را درست نفهمیده یا قصد دارد هر چیز اضافه را بعداً جداگانه حساب کند. این پرسش‌ها کمک میکنند تفاوت‌ها را ببینید:
- آیا مرحله‌ی تحلیل نیاز جدا تعریف شده و خروجی آن سندی است که پیش از برنامهنویسی تأیید میکنید؟
- آیا پیش از برنامهنویسی نمونهی اولیه‌ی قابل کلیک می‌بینید؟
- کد منبع، مستندات و دسترسی به مخزن کد در کدام مرحله و با چه شرطی تحویل داده میشود؟
- در طول پروژه هر چند وقت یکبار نسخهی قابل آزمایش می‌بینید؟
- چه کسی مسئول ارتباط با شماست و اگر او از شرکت برود، پروژه چطور ادامه پیدا میکند؟
- آیا می‌توانید نمونه‌ای از سامانههایی که ساخته‌اند ببینید، حتی اگر به دلیل محرمانگی فقط به شکل نمایشی باشد؟
نزدیکی جغرافیایی هم برای پروژه‌های بزرگ‌تر ارزش دارد، چون جلسه‌های تحلیل حضوری و دیدن فرایند از نزدیک، خیلی از سوءتفاهم‌ها را از ابتدا حذف میکند. اگر در شیراز یا استان فارس هستید، صفحه‌ی طراحی نرمافزار در شیراز نحوه‌ی کار حضوری ما را توضیح میدهد.
قدم بعدی چیست؟
پیش از هر تماسی، یک صفحه بنویسید: کاربران سامانه چه کسانی‌اند، کار اصلی از کجا شروع و به کجا ختم میشود، کدام گزارش را هر هفته میخواهید و سامانه باید به چه چیزهایی وصل شود. همین یک صفحه گفتگو با هر شرکت سازنده‌ای را دقیق‌تر و پیشفاکتورها را قابل مقایسه میکند. اگر خواستید آن را با ما مرور کنید، فرم مشاوره را پر کنید؛ در جلسه‌ی اول درباره‌ی فرایندتان صحبت می‌کنیم و اگر به این نتیجه رسیدیم که یک نرمافزار آماده برایتان کافی است، همین را می‌گوییم.
