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

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

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

چهار صنعت، چهار جریان کاری

نباید همه کسب‌وکارها را با یک Workflow طراحی کرد.

سامانه مالی و مودیان باید در انتهای همین جریان طبیعی قرار بگیرند، نه اینکه یک مسیر موازی و جدا بسازند.

مثال یک شرکت تولیدی

مشتری 1000 قطعه سفارش می‌دهد. بخش تولید 1000 قطعه آماده می‌کند. کنترل کیفیت 985 قطعه را تأیید می‌کند. انبار 985 قطعه تحویل می‌دهد. اما بخش فروش چون به اطلاعات کنترل کیفیت دسترسی ندارد، براساس سفارش اولیه 1000 عدد فاکتور می‌کند. این مسئله با خرید یک «نرم‌افزار فاکتور بهتر» حل نمی‌شود. مشکل این است که داده تأییدشده از کنترل کیفیت و انبار به فروش نرسیده است.

هر داده باید صاحب داشته باشد

یکی از اصول مهم معماری سازمانی این است که مشخص باشد منبع معتبر هر داده کجاست.

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

مسئله واقعی «اتصال» است، نه الزاماً «تعویض»

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

جای سامانه مودیان در معماری سازمان کجاست؟

سامانه مودیان نباید محل ایجاد اولیه اطلاعات فروش باشد. در معماری مناسب: عملیات شرکت ← اطلاعات نهایی فروش/خدمت ← سیستم مالی یا فروش ← لایه صورتحساب الکترونیکی ← سامانه مودیان. یعنی صورتحساب الکترونیکی خروجی داده کنترل‌شده سازمان است. در این معماری، حساب آنلاین می‌تواند لایه مربوط به ثبت، ارسال و مدیریت صورتحساب را پوشش دهد؛ بدون اینکه ادعا کند جای ERP، انبار، تولید یا مدیریت پروژه را می‌گیرد.

شرکت خدماتی هم مسئله یکپارچگی دارد؛ فقط شکلش متفاوت است

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

معدن؛ داده فیزیکی وارد سیستم مالی می‌شود

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

اگر واحد آلاینده باشد، یک جریان دیگر اضافه می‌شود

اینجا آلایندگی سر جای واقعی خودش قرار می‌گیرد. یک کارخانه، معدن یا واحد خدماتی ابتدا همان فرآیند عملیاتی و مالی خودش را دارد. اگر طبق تشخیص سازمان حفاظت محیط‌زیست در وضعیت واحد آلاینده موضوع ماده 27 قرار گیرد، یک جریان اطلاعاتی دیگر نیز اهمیت پیدا می‌کند: HSE / محیط‌زیست ← مدیریت ← مالی و مالیاتی. ماده 27 برای واحدهای مشمول، عوارض سبز 0٫5، 1 یا 1٫5 درصد را براساس معیارهای آلایندگی و مأخذ فروش پیش‌بینی می‌کند. همچنین فروش این واحدها برای محاسبات ماده 27 از سامانه مودیان یا اظهارنامه مربوط قابل تعیین است. بنابراین اگر وضعیت آلایندگی در HSE باقی بماند و به مالی منتقل نشود، سازمان یک شکاف فرآیندی دارد.

داشبورد مدیرعامل باید چه چیزی نشان دهد؟

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

چه زمانی نرم‌افزار سفارشی توجیه دارد؟

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

نقش جادوی فکر

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

تفاوت دیجیتالی‌کردن و نرم‌افزاری‌کردن

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

جمع‌بندی

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

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

درخواست مشاوره و دمو