مقاله 11 دقیقه مطالعه

وقتی حافظه سازمان در Excel است، چطور از آن محافظت کنیم؟

وقتی فایل‌های Excel به بخشی از حافظه سازمان تبدیل می‌شوند، Backup به‌تنهایی کافی نیست. این نوشته درباره مالکیت اطلاعات، Source of Truth، کنترل دسترسی، Versioning، مستندسازی، Offboarding و زمان مناسب بازنشسته‌کردن Excel است.

در بسیاری از شرکت‌ها بخشی از مهم‌ترین اطلاعات سازمان هنوز در Excel زندگی می‌کند.

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

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

من الزاماً این را نشانه عقب‌ماندگی سازمان نمی‌دانم.

Excel ابزار فوق‌العاده‌ای است.

سریع است، انعطاف‌پذیر است، تقریباً همه آن را می‌شناسند و برای بسیاری از مسائل، ساختن یک فایل Excel بسیار منطقی‌تر از توسعه یک نرم‌افزار جدید است.

مسئله از جای دیگری شروع می‌شود:

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


فایل متعلق به چه کسی است؟

این شاید اولین سؤال باشد.

فرض کنید یکی از کارشناسان بازرگانی طی چهار سال فایل بسیار خوبی ساخته است.

اطلاعات صدها خرید در آن قرار دارد.

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

فایل روی Desktop لپ‌تاپ خودش است.

اسمش هم شاید چیزی شبیه این باشد:

Purchase Final 1405 - NEW - Last.xlsx

همه هم می‌دانند برای پیدا کردن فلان اطلاعات باید از او بپرسند.

در ظاهر شرکت یک فایل Excel دارد.

در واقعیت، یک کارمند یک پایگاه داده شخصی دارد که شرکت به آن وابسته شده است.

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

مشکل زمانی خودش را نشان می‌دهد که لپ‌تاپ خراب شود، فایل Corrupt شود، کارمند مرخصی باشد، شرکت را ترک کند، رابطه کاری نامناسب تمام شود یا حتی صرفاً اشتباهی چند Sheet یا چند هزار ردیف پاک شود.

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


مسئله فقط Backup نیست

اولین راه‌حلی که معمولاً به ذهن می‌رسد Backup است.

Backup لازم است، اما کافی نیست.

فرض کنید هر شب از فایل‌ها Backup داریم.

هنوز سؤال‌های دیگری باقی است:

چه کسی اجازه مشاهده فایل را دارد؟

چه کسی می‌تواند آن را تغییر دهد؟

چه کسی می‌تواند حذفش کند؟

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

اگر اطلاعات اشتباهی تغییر کرد، می‌فهمیم چه اتفاقی افتاده؟

اگر فرمول مهمی پاک شد، نسخه قبلی را داریم؟

اگر مسئول فایل از شرکت رفت، نفر بعدی می‌داند فایل چگونه کار می‌کند؟

کدام نسخه، نسخه اصلی است؟

چه کسی Owner اطلاعات است؟

Backup فقط به یکی از این سؤال‌ها جواب می‌دهد.

مدیریت اطلاعات مسئله بزرگ‌تری از Backup است.


اولین اصل: فایل سازمانی نباید روی کامپیوتر یک فرد زندگی کند

اگر فایلی برای سازمان مهم است، محل اصلی آن نباید Desktop، Documents، فلش، هارد شخصی یا لپ‌تاپ یک کارمند باشد.

نسخه اصلی باید در یک مخزن سازمانی مدیریت‌شده قرار بگیرد.

این مخزن بسته به زیرساخت شرکت می‌تواند File Server سازمان، Document Management System یا سرویسی مانند SharePoint/OneDrive for Business باشد.

برای مثال در اکوسیستم Microsoft 365، فایل‌های Excel ذخیره‌شده در OneDrive یا SharePoint می‌توانند به‌صورت هم‌زمان توسط چند نفر ویرایش شوند و Version History نیز امکان مشاهده و بازیابی نسخه‌های قبلی را فراهم می‌کند. Microsoft Support

اما اصل مهم‌تر از محصول است:

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

این تفاوت کوچکی نیست.


دومین اصل: یک Source of Truth داشته باشیم

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

Sales.xlsx
Sales-new.xlsx
Sales-final.xlsx
Sales-final2.xlsx
Sales-Reza.xlsx
Sales-1405-final.xlsx
Sales-1405-final-last.xlsx

و بعد سؤال معروف:

«کدومش آخریه؟»

این فقط بی‌نظمی فایل نیست.

یک مشکل مدیریتی است.

چون وقتی دو مدیر براساس دو نسخه متفاوت از یک گزارش تصمیم می‌گیرند، دیگر مسئله Excel نیست؛ مسئله Single Source of Truth است.

برای فایل‌های مهم باید مشخص باشد:

نسخه اصلی کجاست، چه کسی مسئول آن است و سایر نسخه‌ها چه وضعیتی دارند.

در محیط‌هایی مثل SharePoint و OneDrive، Version History کمک می‌کند به‌جای تکثیر دستی فایل برای حفظ نسخه‌های قبلی، تاریخچه نسخه‌ها نگهداری و در صورت نیاز نسخه قبلی بازیابی شود. Microsoft Support


سومین اصل: همه کسانی که اطلاعات را می‌بینند، نباید بتوانند آن را تغییر دهند

در بسیاری از شرکت‌ها مدل دسترسی تقریباً صفر و یک است:

یا فایل را نداری، یا داری.

اما دسترسی باید لایه‌بندی شود.

ممکن است ۲۰ نفر نیاز داشته باشند گزارش فروش را ببینند، ولی فقط ۳ نفر لازم باشد اطلاعات خام آن را تغییر دهند.

ممکن است یک کاربر فقط مسئول ورود اطلاعات باشد، ولی نباید فرمول‌ها و ساختار Workbook را تغییر دهد.

ممکن است مدیر نیاز به مشاهده داشته باشد، نه Edit.

خود Excel امکاناتی مثل Protect Sheet، Protect Workbook و محدود کردن Rangeهای قابل ویرایش دارد. Microsoft نیز تأکید می‌کند که Workbook/Worksheet Protection را نباید با امنیت کامل فایل اشتباه گرفت؛ برای اطلاعات حساس باید کنترل‌های دسترسی و امنیتی مناسب در سطح فایل و زیرساخت هم وجود داشته باشد. Microsoft Support

این تفکیک مهم است:

Protection داخل Excel ≠ Information Security

قفل کردن چند Cell جلوی اشتباه را می‌گیرد.

کنترل دسترسی سازمانی جلوی دسترسی غیرمجاز را.

این دو جای یکدیگر را نمی‌گیرند.


چهارمین اصل: برای اشتباه آدم خوب هم طراحی کنیم

وقتی درباره محافظت از اطلاعات صحبت می‌کنیم، ذهن سریع سراغ کارمند ناراضی یا خرابکاری عمدی می‌رود.

اما به نظرم تهدید رایج‌تر بسیار ساده‌تر است:

اشتباه.

کسی یک Column را Sort می‌کند ولی بقیه جدول را انتخاب نکرده است.

یک Formula را با Value جایگزین می‌کند.

چند هزار ردیف را پاک می‌کند.

روی فایل اصلی چیزی Paste می‌کند.

Sheet را حذف می‌کند.

فایل را با نسخه قدیمی جایگزین می‌کند.

یا فکر می‌کند:

«این فایل دیگه لازم نیست.»

و Delete می‌زند.

برای همین Version History اهمیت زیادی دارد. در Microsoft 365، برای فایل‌های نگهداری‌شده در OneDrive یا SharePoint می‌توان نسخه‌های قبلی را مشاهده و در صورت لزوم بازیابی کرد. Microsoft Support

سیستم خوب نباید فقط در برابر آدم بد مقاوم باشد.

باید در برابر اشتباه آدم خوب هم مقاوم باشد.


اما سناریوی کارمند ناراضی را هم نباید نادیده گرفت

صحبت درباره این موضوع شاید خوشایند نباشد، ولی از نظر مدیریت ریسک باید آن را دید.

فرض کنیم کارمندی که چند سال اطلاعات مهمی را مدیریت کرده تصمیم به ترک شرکت می‌گیرد.

رابطه هم خوب تمام نمی‌شود.

چه اتفاقی می‌تواند بیفتد؟

مسئله فقط این نیست که ممکن است فایلی را حذف کند.

ممکن است اطلاعات را تغییر دهد.

ممکن است فایل را با خودش ببرد.

ممکن است Passwordهایی وجود داشته باشند که فقط خودش می‌داند.

ممکن است Macro یا Formula پیچیده‌ای ساخته باشد که هیچ‌کس دیگری از منطق آن سر درنیاورد.

حتی ممکن است هیچ اقدام مخربی انجام ندهد؛ فقط برود.

و تازه بعد از رفتنش بفهمیم:

بخشی از دانش سازمان همراه او رفته است.

بنابراین مسئله اصلی نباید «چطور جلوی انتقام کارمند را بگیریم؟» باشد.

این نگاه خیلی محدود است.

سؤال حرفه‌ای‌تر این است:

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

این سؤال درباره بی‌اعتمادی نیست.

درباره Business Continuity است.


مالک فایل نباید همان کسی باشد که تنها دانش کار با آن را دارد

اینجا یک ریسک پنهان دیگر وجود دارد.

فرض کنید Backup عالی داریم.

فایل هم روی Server است.

دسترسی‌ها هم تنظیم شده‌اند.

اما یک فایل Excel داریم با ۲۵ Sheet، ده‌ها Lookup، Power Query، Macro و Formula که فقط سازنده آن می‌فهمد چگونه کار می‌کند.

از نظر IT فایل را حفظ کرده‌ایم.

اما از نظر سازمانی هنوز وابسته‌ایم.

وابستگی فقط وابستگی به فایل نیست؛ وابستگی به دانش کار با فایل هم هست.

برای فایل‌های حیاتی باید حداقل مستندات ساده‌ای داشته باشیم:

هدف این فایل چیست؟

داده از کجا وارد می‌شود؟

کدام Sheetها Input هستند؟

کدام‌ها Output؟

چه قسمت‌هایی نباید دستی تغییر کنند؟

فرمول‌های حساس کدام‌اند؟

چه کسی Owner کسب‌وکاری فایل است؟

چه کسی Backup Owner است؟

هر چند وقت یک بار Update می‌شود؟

اگر مشکلی ایجاد شد چه کسی می‌تواند آن را بازیابی کند؟

لازم نیست برای هر Excel یک کتابچه ۵۰ صفحه‌ای بنویسیم.

گاهی یک Sheet به نام README کافی است.

اما فایل حیاتی بدون Documentation یعنی دانش سازمانی‌ای که هنوز به دانش شخصی وابسته است.


Excelهای سازمان را طبقه‌بندی کنیم

به نظرم لازم نیست برای تمام فایل‌های Excel شرکت چنین سخت‌گیری‌ای داشته باشیم.

فایل محاسبات شخصی یک کارشناس با فایلی که قیمت خرید پنج سال شرکت داخل آن است، یکسان نیست.

من فایل‌ها را حداقل از نظر اهمیت به سه سطح تقسیم می‌کنم:

عادی: از بین رفتنش آزاردهنده است، اما قابل بازسازی است.

مهم: از بین رفتنش باعث اتلاف زمان، هزینه یا اختلال عملیاتی می‌شود.

حیاتی: از بین رفتن، تغییر غیرقابل‌بازیابی یا افشای آن می‌تواند عملیات، پول، مشتری، تعهدات یا تصمیم‌های مهم سازمان را تحت تأثیر قرار دهد.

بعد میزان Backup، Access Control، Versioning، Documentation و Monitoring را متناسب با اهمیت فایل تعیین کنیم.

قرار نیست از فایل برنامه ناهار شرکت مثل فایل قیمت‌گذاری یا حقوق و دستمزد محافظت کنیم.


Backup باید مستقل از کاربر باشد

یکی از اشتباهات رایج این است که Backup هم به کاربر سپرده شود.

«هر هفته یک Copy بگیر.»

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

Backup باید تا حد امکان خودکار، قابل کنترل و قابل بازیابی باشد.

و نکته مهم‌تر:

داشتن Backup با توانایی Restore کردن یکی نیست.

Backupی که هیچ‌وقت آزمایش نشده، تا روز حادثه فقط یک فرض است.

سازمان باید گاهی واقعاً امتحان کند:

اگر امروز این فایل از بین رفت، می‌توانیم نسخه سالم دیروز یا هفته قبل را برگردانیم؟


حذف اطلاعات نباید به معنی نابودی اطلاعات باشد

برای اطلاعات مهم، Delete نباید لزوماً پایان داستان باشد.

معماری نگهداری اطلاعات باید متناسب با حساسیت آن امکان Recovery، Versioning و Retention مناسب داشته باشد.

این موضوع به‌خصوص وقتی اهمیت دارد که چند نفر روی یک فایل کار می‌کنند. Microsoft هم برای همکاری در Excel استفاده از Versioning را توصیه می‌کند تا در صورت اشتباه امکان بازگرداندن نسخه قبلی وجود داشته باشد. Microsoft Support

اینجا یک اصل مدیریتی مهم وجود دارد:

قدرت تغییر اطلاعات و قدرت نابود کردن تاریخچه اطلاعات لزوماً نباید یکی باشد.

کسی ممکن است برای انجام کار روزانه به Edit نیاز داشته باشد.

این الزاماً به این معنی نیست که باید بتواند همه سوابق سازمان را برای همیشه از بین ببرد.


خروج کارمند باید یک فرآیند اطلاعاتی هم داشته باشد

Offboarding را معمولاً از منظر منابع انسانی می‌بینیم:

تسویه حساب، تحویل تجهیزات، کارت ورود، خداحافظی.

اما خروج یک نیروی کلیدی باید یک Data Handover هم داشته باشد.

قبل از خروج باید مشخص شود چه فایل‌هایی در اختیار اوست، کدام فایل‌ها فقط روی دستگاهش هستند، چه اطلاعاتی باید منتقل شود، چه فایل‌هایی Owner جدید می‌خواهند، چه Automation/Macroهایی ساخته، چه Password یا Credential سازمانی باید طبق سیاست شرکت تغییر کند و چه دانش کاری باید مستند یا منتقل شود.

این کار را بهتر است روز آخر انجام ندهیم.

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


یک فایل Excel چه زمانی باید بازنشسته شود؟

به نظرم این بخش برای مقاله خیلی مهم است.

هدف نباید این باشد که Excel را برای همیشه امن‌تر و پیچیده‌تر کنیم.

گاهی مشکل اصلی این است که اطلاعات دیگر نباید در Excel باشند.

اگر فایلی:

هر روز توسط چند نفر استفاده می‌شود،

برای عملیات حیاتی است،

سطوح دسترسی متفاوت می‌خواهد،

حجم داده مرتب در حال رشد است،

نیاز به Audit Trail جدی دارد،

با چند فرآیند دیگر در ارتباط است،

خطای ورود اطلاعات در آن هزینه زیادی دارد،

یا برای تصمیم‌های حیاتی شرکت Source of Truth شده است،

شاید زمان آن رسیده باشد که بخشی از آن به ERP، CRM، Database، DMS یا نرم‌افزار مناسب منتقل شود.

Excel ابزار فوق‌العاده‌ای برای تحلیل و انعطاف است.

اما هر Excel موفقی نباید الزاماً تا ابد Excel باقی بماند.

گاهی موفقیت یک فایل Excel دقیقاً باعث می‌شود که از Excel بزرگ‌تر شود.


یک تست ساده برای مدیران

اگر بخواهم این نوشته را به یک تمرین تبدیل کنم، از مدیر شرکت می‌خواهم فردا صبح فقط یک سؤال از واحدهایش بپرسد:

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

جواب‌ها احتمالاً جالب خواهند بود.

بعد سؤال دوم:

اگر آن فرد فردا دیگر به شرکت نیاید، چه فایل‌هایی داریم که هیچ‌کس دقیقاً نمی‌داند چگونه کار می‌کنند؟

و سؤال سوم:

اگر یکی از فایل‌های مهم امروز اشتباه یا عمداً تغییر کند، آیا می‌توانیم بفهمیم چه اتفاقی افتاده و نسخه سالم را برگردانیم؟

اگر جواب یکی از این سؤال‌ها «نمی‌دانم» است، احتمالاً یک ریسک اطلاعاتی پیدا کرده‌ایم.


شاید مشکل Excel نباشد

من با این جمله که «شرکت حرفه‌ای نباید Excel داشته باشد» موافق نیستم.

تقریباً برعکس.

Excel احتمالاً برای سال‌های زیادی یکی از ابزارهای مهم کسب‌وکار باقی خواهد ماند.

مشکل این نیست که اطلاعات در Excel هستند.

مشکل زمانی است که اطلاعات مهم سازمان در Excel هستند، اما هیچ‌کس مسئول معماری نگهداری آنها نیست.

فایل‌ها روی سیستم افراد پراکنده‌اند.

Backup به حافظه کاربر وابسته است.

دسترسی‌ها مشخص نیست.

Version History نداریم.

نسخه اصلی معلوم نیست.

فایل مستند نشده است.

جانشین ندارد.

و گاهی حتی مدیریت نمی‌داند چه اطلاعات مهمی در چه فایل‌هایی نگهداری می‌شود.

در چنین شرایطی ما فقط به Excel وابسته نیستیم.

به آدم‌هایی وابسته‌ایم که Excelها را در اختیار دارند.

و این دو نوع وابستگی کاملاً متفاوت‌اند.

هدف سیستم‌سازی هم حذف آدم‌ها نیست.

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

شاید اولین قدم هم خرید ERP جدید نباشد.

گاهی اولین قدم خیلی ساده‌تر است:

بفهمیم Excelهای حیاتی شرکت کجا هستند، چه کسی به آنها دسترسی دارد، چه کسی مسئولشان است و اگر فردا از بین رفتند، چه برنامه‌ای داریم.

از همین چهار سؤال، بخش بزرگی از مسیر مشخص می‌شود.

برای بعد یا برای دیگران این نوشته را نگه دارید یا به اشتراک بگذارید