هنگام انتخاب نرم‌افزارهای سازمانی، معمولاً چند سؤال زودتر از بقیه مطرح می‌شود: قیمت چقدر است؟ چقدر سریع راه‌اندازی می‌شود؟ از خارج شرکت هم می‌توان به آن دسترسی داشت؟
اما برای انتخاب نرم افزار های هوش تجاری (BI)، ERP، CRM، و حتی نرم‌افزارهای واسط سامانه مؤدیان، یک سؤال دیگر هم باید از همان ابتدا روی میز باشد:
داده‌های کسب‌وکار ما کجا پردازش می‌شوند، چه کسانی امکان دسترسی به آن‌ها را دارند و این دسترسی چگونه کنترل می‌شود؟
پاسخ این سؤال، بخشی از هزینه واقعی و ریسک بلندمدت نرم‌افزار را مشخص می‌کند.
نرم‌افزارهای تحت وب می‌توانند به شکل‌های مختلفی مستقر شوند. در مدل ابریِ اشتراکی یا SaaS، نرم‌افزار روی زیرساختی اجرا می‌شود که ارائه‌دهنده مدیریت می‌کند؛ این زیرساخت ممکن است متعلق به خود او یا یک شرکت خدمات ابری دیگر باشد. کاربران نیز معمولاً از طریق اینترنت به سامانه متصل می‌شوند.
در استقرار در محل یا On-Premises، نرم‌افزار روی زیرساخت داخلی سازمان اجرا می‌شود و می‌تواند از طریق شبکه داخلی در دسترس باشد. البته امکان کار بدون اینترنت، به طراحی نرم‌افزار، سازوکار مجوز و وابستگی آن به سرویس‌های بیرونی بستگی دارد. برای نمونه، یک نرم‌افزار واسط مالیاتیِ داخلی هم برای ارسال اطلاعات به سامانه مقصد، به ارتباط بیرونی نیاز خواهد داشت.
ابر خصوصی، میزبانی اختصاصی و استقرار ترکیبی نیز گزینه‌های دیگری هستند. بنابراین، انتخاب مدل استقرار باید بر اساس معماری واقعی سرویس انجام شود؛ عنوان «ابری» یا «داخلی» به‌تنهایی توضیح کافی نمی‌دهد.
داده‌های عملیاتی شما، نقشهای از استراتژی شما هستند.
اطلاعات موجود در نرم‌افزارهای سازمانی فقط تعدادی سند، فاکتور یا نمودار نیستند. کنار هم قرار گرفتن آن‌ها می‌تواند نشان دهد:
کدام مشتریان برای سازمان حیاتی‌اند و وابستگی درآمدی به آن‌ها چقدر است.
سیاست قیمت‌گذاری، تخفیف و شرایط اعتباری چگونه تعیین می‌شود.
کدام محصول، شعبه یا پروژه حاشیه سود بالاتری دارد.
سازمان در چه زمان‌هایی با فشار نقدینگی مواجه می‌شود.
تأمین‌کنندگان کلیدی چه کسانی هستند و چه شرایطی برای همکاری دارند.
برنامه توسعه بازار، افزایش ظرفیت یا تغییر ترکیب فروش به چه سمت می‌رود.
ممکن است هیچ سندی با عنوان «استراتژی محرمانه شرکت» در سامانه وجود نداشته باشد، اما تحلیل همین داده‌ها بتواند بخش‌هایی از آن استراتژی را آشکار کند.
این موضوع در سامانه‌های هوش تجاری حساس‌تر می‌شود؛ زیرا BI داده‌های پراکنده مالی، فروش، انبار، عملیات و منابع انسانی را به یکدیگر متصل می‌کند. همین یکپارچگی که برای مدیران ارزش می‌سازد، ارزش و حساسیت اطلاعات قابل دسترسی را نیز افزایش می‌دهد.
وقتی این داده‌ها روی زیرساخت ارائه‌دهنده پردازش می‌شوند، دامنه اعتماد سازمان به ارائه‌دهنده، کارکنان دارای دسترسی و پیمانکاران مرتبط گسترش پیدا می‌کند. این اعتماد باید با کنترل فنی، تعهد قراردادی و امکان راستی‌آزمایی همراه باشد.
ریسک افشا فقط به حمله سایبری محدود نیست.
دسترسی گسترده تیم پشتیبانی، حساب مدیریتی مشترک، فایل خروجی ارسال‌شده برای رفع خطا، نسخه پشتیبان محافظت‌نشده یا داده واقعی کپی‌شده در محیط آزمایش، همگی می‌توانند مسیر افشای اطلاعات باشند.
حتی دسترسی اولیه مجاز نیز باید محدوده و مدت مشخص داشته باشد. برای مثال، نیاز پشتیبان به بررسی یک خطای گزارش‌گیری، لزوماً دسترسی دائمی به همه اطلاعات مالی و مشتریان را توجیه نمی‌کند.
پرسش‌های عملی در این بخش روشن‌اند: چه کسی به داده دسترسی دارد؟ برای چه کاری؟ با تأیید چه فردی؟ برای چه مدتی؟ و آیا سازمان می‌تواند سابقه این دسترسی را بررسی کند؟
امنیت در سرویس ابری، مسئولیتی مشترک است.
در مدل SaaS، ارائه‌دهنده معمولاً مسئول بخش بزرگی از امنیت زیرساخت و نرم‌افزار است؛ اما مدیریت کاربران، تعیین نقش‌ها، حفاظت از حساب‌های سازمانی و نحوه اشتراک‌گذاری اطلاعات همچنان به تصمیم‌های مشتری وابسته‌اند. مرز دقیق این مسئولیت‌ها باید در قرارداد و مستندات سرویس مشخص شود.
یک حساب مدیر بدون احراز هویت چندمرحله‌ای، لینک گزارش با دسترسی عمومی یا مجوز بیش‌ازحد یک کاربر می‌تواند کنترل‌های دیگر را کم‌اثر کند.
از سوی دیگر، عبارت‌هایی مانند «داده‌ها رمزگذاری می‌شوند» به توضیح بیشتری نیاز دارند. رمزگذاری هنگام انتقال و ذخیره‌سازی ضروری است، اما به‌تنهایی به معنای ناممکن بودن دسترسی ارائه‌دهنده به محتوای داده نیست. باید روشن شود کلیدها در اختیار چه کسی است و نرم‌افزار و مدیران آن در چه شرایطی به داده رمزگشایی‌شده دسترسی دارند.
متادیتا و لاگ‌ها نیز دارایی حساس‌اند.
زمان ورود مدیران، دفعات مشاهده یک گزارش، نام فایل‌های خروجی، عنوان داشبوردها، حجم تراکنش‌ها و زمان افزایش فعالیت کاربران می‌توانند الگوهای مهمی از رفتار سازمان را نشان دهند.
برای مثال، مشاهده مکرر گزارش مطالبات و نقدینگی در یک بازه خاص ممکن است نشانه تمرکز مدیریتی بر وصول مطالبات باشد؛ البته چنین برداشتی بدون زمینه و شواهد تکمیلی قطعی نیست.
لاگ‌ها برای امنیت و عیب‌یابی لازم‌اند، اما باید معلوم باشد چه اطلاعاتی در آن‌ها ثبت می‌شود، چه کسانی آن‌ها را می‌بینند و چه زمانی حذف می‌شوند. ثبت بی‌ضابطه محتوای درخواست‌ها نیز ممکن است اطلاعات مالی، شناسه‌ها یا حتی اطلاعات احراز هویت را وارد لاگ کند.
حاکمیت داده، از محل پایگاه داده فراتر می‌رود.
برای ارزیابی محل نگهداری اطلاعات، بررسی سرور اصلی کافی نیست. نسخه‌های پشتیبان، محیط بازیابی بحران، سرویس‌های ثبت رخداد، ابزارهای پشتیبانی و پیمانکاران فرعی نیز باید در نظر گرفته شوند.
تعهدات قراردادی و الزامات قانونی مرتبط، به محل پردازش، شخصیت حقوقی ارائه‌دهنده، نوع داده و مقررات قابل اعمال بستگی دارند. صرف استقرار داخلی نیز همه تعهدات قانونی سازمان را از بین نمی‌برد.
همچنین باید مشخص باشد استفاده ثانویه از داده چه محدودیت‌هایی دارد: آیا داده صرفاً برای ارائه همان خدمت پردازش می‌شود؟ آیا استفاده از آن برای تحلیل تجاری، توسعه محصول یا آموزش مدل‌های هوش مصنوعی مجاز است؟ این موارد باید صریح و قابل بررسی باشند.
هزینه کمترِ شروع، لزوماً به معنای هزینه کمترِ مالکیت نیست.
سرویس ابری می‌تواند سرمایه‌گذاری اولیه، زمان راه‌اندازی و بخشی از بار نگهداری را کاهش دهد. این مزیت، به‌ویژه برای سازمان‌هایی با تیم فناوری اطلاعات کوچک، ارزشمند است.
با این حال، مقایسه اقتصادی باید کل دوره استفاده را پوشش دهد:
هزینه اشتراک، افزایش تعداد کاربران، رشد داده و قابلیت‌های تکمیلی.
هزینه اتصال به سامانه‌های دیگر و محدودیت‌های API یا خروجی‌گیری.
هزینه اختلال سرویس یا قطع ارتباط اینترنتی.
هزینه دریافت، نگهداری و بازیابی نسخه مستقل از داده‌ها.
هزینه مهاجرت به محصول دیگر و وابستگی به تأمین‌کننده.
پیامدهای احتمالی رخداد امنیتی، از توقف عملیات تا آسیب به اعتماد مشتریان.
در مقابل، استقرار داخلی نیز هزینه خرید و نوسازی تجهیزات، نیروی متخصص، پایش امنیتی، به‌روزرسانی، پشتیبان‌گیری و بازیابی بحران دارد.
محل سرور به‌تنهایی معیار امنیت نیست.
یک سرویس ابری با مدیریت حرفه‌ای ممکن است از یک سرور داخلی بدون وصله امنیتی و بدون پشتیبان قابل بازیابی، امن‌تر باشد. استقرار داخلی کنترل مستقیم بیشتری ایجاد می‌کند، اما بهره‌برداری از این کنترل به توان فنی و انضباط عملیاتی سازمان وابسته است.
پیش از انتخاب، این سؤال‌ها را از ارائه‌دهنده بپرسیم:
داده اصلی، نسخه‌های پشتیبان و لاگ‌ها دقیقاً کجا نگهداری می‌شوند؟
دسترسی کارکنان و پیمانکاران شما چگونه محدود، تأیید و ثبت می‌شود؟
جداسازی داده مشتریان چگونه انجام می‌شود و چه شواهدی برای ارزیابی آن وجود دارد؟
احراز هویت چندمرحله‌ای، نقشهای دسترسی و گزارش رخدادهای قابل بررسی برای مشتری فراهم است؟
رمزگذاری و مدیریت کلیدها چگونه انجام می‌شود؟
در رخداد امنیتی، چه فرایند و تعهدی برای اطلاع‌رسانی و رسیدگی دارید؟
حداکثر زمان هدف برای بازیابی سرویس وثر زمان هدف برای بازیابی سرویس و حداکثر میزان ازدست و آیا بازیابی آزمایش می‌شود؟
آیا می‌توان داده‌ها، پیوست‌ها و اطلاعات لازم برای مهاجرت را در قالبی مستند و قابل استفاده دریافت کرد؟
پس از پایان قرارداد، اطلاعات چه زمانی و با چه روشی حذف می‌شوند و وضعیت نسخه‌های پشتیبان چیست؟
آیا استفاده ثانویه از داده‌ها، از جمله برای آموزش هوش مصنوعی، به رضایت صریح مشتری وابسته است؟
برای برخی سازمان‌ها، SaaS با کنترل‌ها و تعهدات روشن انتخاب مناسبی است. برای برخی دیگر، حساسیت اطلاعات و نیاز به کنترل مستقیم، استقرار داخلی یا خصوصی را توجیه می‌کند. در معماری ترکیبی نیز می‌توان بخشی از پردازش را بیرون از سازمان انجام داد؛ به شرط آنکه مرز داده‌ها و مسیر جابه‌جایی آن‌ها دقیق طراحی شود.
انتخاب محل استقرار نرم‌افزار، یک تصمیم مدیریتی درباره هزینه، تداوم فعالیت و حدود اعتماد است.
پیش از تصمیم‌گیری، باید ارزش داده، پیامد افشا یا عدم دسترسی به آن و توان سازمان برای اداره هر مدل مشخص شود. تخفیف خرید یا سرعت راه‌اندازی، تنها بخشی از این محاسبه‌اند.
شما فقط نرم‌افزار انتخاب نمی‌کنید؛ تعیین می‌کنید چه کسی، تحت چه شرایطی، به بخشی از تصویر واقعی کسب‌وکارتان دسترسی داشته باشد.
#آموزشی #تحلیل_نرم_افزار #هوش_تجاری #حاکمیت_داده #امنیت_اطلاعات #GoBI #BI #ERP #CRM #Cloud #On_Premises #CyberSecurity #InformationSecurity
