07
مهیکی از ترسناکترین صحنهها در این پلتفرمها، جستجوی یک سند مهم مانند قرارداد یا گزارش پروژه و پیدا کردن دهها نسخه مشابه اما با تفاوتهای جزئی است. کاربران به دلیل عدم اطمینان از آخرین نسخه، فایلها را کپی میکنند و نامهای جدیدی برای آنها میگذارند. پس از مدتی، هیچکس نمیداند کدام نسخه معتبر است و آیا تغییرات تیم مالی در نسخه خودشان با ویرایشهای تیم فنی در نسخه دیگر هماهنگ شده است یا خیر.
این آشفتگی میتواند به تصمیمگیریهای غلط بر اساس اطلاعات منسوخ منجر شود و عواقب مالی یا حقوقی جدی به همراه داشته باشد. علاوه بر این، فضای ذخیرهسازی سرور به سرعت با نسخههای تکراری اشغال میشود و هزینههای زیرساخت را افزایش میدهد. مدیریت این وضعیت مانند پیدا کردن سوزن در انبار کاهی میماند که خود آن انبار هم پر از کاههای مشابه اما متفاوت است.
ایده اصلی استفاده از این سیستمها، ایجاد یک منبع معتبر و واحد برای اطلاعات است. اما در عمل، این ایده به سرعت میمیرد. افراد یا تیمهای مختلف شروع به ساخت سایتها، کتابخانهها یا لیستهای شخصی خود میکنند. مثلاً تیم منابع انسانی فرمهای داخلی خود را در یک بخش نگه میدارد و تیم پروژه نسخههای دیگری از همان فرمها را برای استفاده اعضای پروژه کپی میکند. وقتی سیاستها بهروز میشوند، بهروزرسانی در همه این مکانهای پراکنده اتفاق نمیافتد.
در نهایت سازمان نه یک، بلکه دهها “منبع” متضاد دارد. این پراکندگی اعتماد به سیستم را از بین میبرد و افراد مجدداً به دامنه امن خود یعنی ایمیل و درایوهای شخصی بازمیگردند و چرخه معیوب تشدید میشود. از بین بردن این عادت پس از شکلگیری، بسیار دشوارتر از پیشگیری از آن در روزهای اول است.
وقتی دادهها پراکنده و تکراری هستند، قابلیت جستجوی قدرتمند این پلتفرمها تبدیل به یک شمشیر دو لبه میشود. کاربر عبارتی را جستجو میکند و با صدها نتیجه روبرو میشود که بسیاری از آنها قدیمی، نامرتبط یا تکراری هستند. تشخیص نتیجه صحیح نیاز به صرف زمان زیادی برای باز کردن و بررسی تکتک فایلها دارد. این امر بهرهوری را به شدت کاهش میدهد و باعث عصبانیت کاربران میشود.
در واقع، سیستم به جای صرفهجویی در زمان، زمان بیشتری را تلف میکند. به مرور زمان، افراد از جستجو ناامید شده و از همکاران خود سؤال میپرسند که این خود باعث ایجاد گلوگاه و اختلال در جریان کار میشود. این هزینه پنهان، شامل از دست دادن زمان جمعی تمام کارکنان است که رقم قابل توجهی خواهد بود.
وجود دادههای پراکنده و تکراری، پیامی مخرب به سازمان میفرستد: “نظم اهمیت ندارد”. هنگامی که کارمندان جدید میبینند سیستم مملو از فایلهای رها شده و نسخههای مختلف است، انگیزه خود برای رعایت انضباط را از دست میدهند. آنها نیز سهم خود را به این بینظمی اضافه میکنند. این مسئله به یک فرهنگ سازمانی منفی تبدیل میشود که در آن هیچکس احساس مسئولیت نمیکند که محتوا را مرتب کند یا از قوانین پیروی نماید.
تغییر این فرهنگ پس از استقرار، نیازمند یک حرکت عظیم و اراده قوی از سوی مدیریت ارشد است. در غیر این صورت، سیستم به یک گورستان دیجیتال از اطلاعات تبدیل میشود که همه از آن متنفرند اما مجبور به استفاده از آن هستند.
تنها راه فرار از این کابوس، وضع قوانین محکم و اجرای آنها از همان روز اول است. باید یک تیم یا فرد به عنوان “مالک محتوا” تعیین شود که مسئول طراحی ساختار اولیه، تعیین استانداردهای نامگذاری و تأیید مکان ایجاد کتابخانههای جدید باشد. استفاده از قابلیتهایی مانند “سند اصلی” که تاریخچه ویرایش را به خوبی ثبت میکند، باید ترویج شود.
آموزش مستمر کاربران درباره عواقب کپی کردن بیرویه و مزایای کار کردن بر روی یک سند مشترک ضروری است. گاهی اوقات، محدود کردن دسترسی ایجاد کتابخانههای جدید فقط برای administrators میتواند از رشد قارچگونه دادهها جلوگیری کند. نظم، یک شبه ایجاد نمیشود، اما با حکمرانی صحیح میتوان از هرج و مرج کامل جلوگیری کرد.
همچنین بخوانید: شیرپوینت، قربانی تصمیم های عجیب سازمانی
یکی از بزرگترین ترسها در این سیستمها، پیچیدگی غیرقابل مدیریت تنظیمات سطوح دسترسی است. هنگامی که مدیر سیستم سعی میکند برای هر تیم و هر نوع سند، دسترسی خاصی تعریف کند، این تنظیمات به سرعت مانند تار عنکبوت پیچیده میشوند. ممکن است به اشتباه به شخصی خارج از تیم، اجازه مشاهده اطلاعات محرمانه مالی داده شود یا برعکس، یکی از اعضای اصلی تیم نتواند به سند مورد نیاز خود دسترسی پیدا کند. هر بار که ساختار سازمانی تغییر میکند یا پروژه جدیدی آغاز میشود، به روزرسانی این دسترسیها به یک کابوس اداری تبدیل میشود. این وضعیت ریسک نشت اطلاعات حساس را به شدت افزایش میدهد و میتواند اعتماد داخلی و حتی تعهدات قانونی را زیر سؤال ببرد.
در نقطه مقابل پیچیدگی، سهلانگاری و اعطای دسترسی بیش از حد و عمومی، خطر دیگری است. برای رهایی از دردسر تنظیمات دقیق، برخی مدیران سیستم، دسترسی «ویرایش کامل» یا حتی «کنترل کامل» را به گروه بزرگی از کاربران میدهند. این کار مانند این است که کلید تمام اتاقهای ساختمان را به هر کارمند بدهید. در این حالت، هر کاربر میتواند به صورت تصادفی یا عمدی، ساختار سایت را تغییر دهد، بخشهای حیاتی را حذف کند یا محتوای دیگران را ویرایش نماید. عواقب این کار میتواند از بین رفتن زحمات ماهها کار باشد. بازگرداندن تغییرات ناخواسته اگر غیرممکن نباشد، بسیار زمانبر و پرهزینه خواهد بود.
با گذشت زمان، افرادی که نقش یا محل کار خود را در سازمان تغییر میدهند یا حتی سازمان را ترک میکنند، همچنان دسترسیهای قدیمی خود را حفظ میکنند. این حسابهای کاربری راکد، یک تهدید امنیتی بزرگ هستند. اگر حساب کاربری یکی از این افراد به خطر بیفتد، فرد مهاجم میتواند به تمام اطلاعاتی که آن کاربر در گذشته به آنها دسترسی داشته، وارد شود. همچنین، حضور این حسابهای غیرفعال در لیستهای دسترسی، مدیران را در بررسی و ممیزی امنیت واقعی سیستم گمراه میکند. پاکسازی منظم این دسترسیها یک وظیفه ضروری اما اغلب فراموششده است.
وقتی کنترل دسترسی به درستی مدیریت نشود، همیشه این احتمال وجود دارد که یک کاربر کمتجربه، به اشتباه یک کتابخانه مهم، یک لیست حاوی اطلاعات پروژه یا حتی یک زیرسایت کامل را حذف کند. در برخی موارد، بازیابی این اطلاعات اگر از قبل پشتیبانگیری منظم و مطمئنی وجود نداشته باشد، کار بسیار دشواری است. حتی اگر اطلاعات بازیابی شوند، اتلاف زمان و ایجاد اختلال در کارها قابل جبران نیست. این ترس، باعث میشود مدیران سیستم همیشه در حالت اضطراری به سر ببرند و کاربران نیز با ترس و لرز با سیستم کار کنند.
کلید حل این مشکل، سادهسازی است. به جای تعیین دسترسی برای تکتک افراد، باید گروههای سازمانی تعریف شود. مثلاً گروه «اعضای تیم مالی»، «مدیران پروژه» یا «کارکنان قراردادی». سپس دسترسیهای لازم به این گروهها داده میشود. وقتی فردی به تیم مالی میپیوندد، فقط به گروه «اعضای تیم مالی» اضافه میشود و به طور خودکار تمام دسترسیهای لازم را دریافت میکند. وقتی سازمان را ترک میکند، از آن گروه حذف میشود. این روش، مدیریت را آسان و ممیزی امنیتی را ممکن میسازد. همچنین، فعالسازی دورههای خودکار بررسی دسترسیها و آموزش کاربران درباره اهمیت امنیت اطلاعات، بخش جداییناپذیر راهکار است.
یکی از رایجترین دلایل کندی سیستم، ایجاد لیستها یا کتابخانههایی است که هزاران هزار آیتم را در خود جای دادهاند. وقتی کاربر سعی میکند چنین لیستی را باز کند یا در آن جستجو نماید، سیستم باید حجم عظیمی از داده را پردازش کند که باعث تأخیرهای طولانی میشود. این اتفاق اغلب زمانی رخ میدهد که از ابتدا برای مدیریت اطلاعات، چارچوب و معماری مناسبی طراحی نشده است. به عنوان مثال، همه فایلهای یک سال کامل در یک پوشه واحد ریخته میشود. این کندی، تجربه کاربری را به شدت تخریب میکند و افراد را از استفاده از سیستم منصرف میکند.
ایجاد نماهای بسیار پیچیده با فیلترها و مرتبسازیهای زیاد، یا استفاده از ستونهای محاسباتی که محاسبات سنگینی را انجام میدهند، میتواند بار زیادی بر سرور وارد کند. به ویژه اگر این نماها به طور خودکار و برای تعداد زیادی کاربر بارگذاری شوند. هر بار که کاربر صفحه را باز میکند، سیستم باید این محاسبات را از ابتدا انجام دهد. اگر تعداد این نماهای پیچیده زیاد باشد، عملکرد کل سایت تحت تأثیر قرار میگیرد. طراحی ضعیف این بخش، میتواند باعث شود سیستم حتی برای انجام سادهترین عملیات نیز زمان زیادی صرف کند.
این پلتفرمها برای مدیریت مستندات و همکاری طراحی شدهاند، نه برای تبدیل شدن به یک سرور ذخیرهسازی فایلهای حجیم ویدئویی، تصویری یا آرشیوهای زیپشده. هنگامی که کاربران فایلهای بسیار بزرگ را مستقیماً در کتابخانهها آپلود میکنند، چند اتفاق میافتد: فضای ذخیرهسازی به سرعت پر میشود، پشتیبانگیری از سیستم طولانی و دشوار میشود و مهمتر از همه، باز کردن یا دانلود این فایلها برای دیگران به یک عملیات کند و طاقتفرسا تبدیل میگردد. این کار بار غیرضروری بر شبکه و سرور وارد میآورد.
برای رفع نیازهای خاص، ممکن است از افزونهها، قطعات وب یا کدهای سفارشی استفاده شود. اگر این افزونهها از منابع معتبر نباشند یا بهینه نوشته نشده باشند، میتوانند باعث ایجاد حفرههای امنیتی یا افت شدید عملکرد شوند. یک قطعه وب سفارشی که به درستی طراحی نشده باشد، ممکن است هر بار که صفحه بارگذاری میشود، دهها درخواست غیرضروری به سرور ارسال کند و باعث قفل شدن یا کندی سیستم شود. مدیریت و بررسی این گونه راهحلهای سفارشی، نیاز به تخصص و زمان دارد.
جلوگیری از این کابوس نیازمند نظارت فعال است. باید سیاستی مبنی بر محدودیت تعداد آیتم در هر لیست یا کتابخانه وضع شود و دادهها به صورت دورهای آرشیو یا بر اساس تاریخ تقسیمبندی گردند. فایلهای حجیم باید در فضای ذخیرهسازی مناسب دیگری قرار گیرند و تنها لینک آنها در سیستم ثبت شود. باید از ایجاد نماهای بسیار پیچیده خودداری و در عوض از فیلترگذاری ساده استفاده کرد. همچنین، استفاده از هرگونه افزونه یا کد سفارشی باید تحت بررسی دقیق و آزمایش عملکرد قرار گیرد. ممیزی دورهای عملکرد سیستم، شناسایی گلوگاهها و رفع آنها، امری ضروری برای حفظ سلامت سیستم است.
یکی از جذابیتهای اصلی این پلتفرمها، امکان ایجاد فرمها و گردشهای کاری است. اما این جذابیت به سرعت به یک کابوس تبدیل میشود وقتی هر بخش یا تیم، بدون در نظر گرفتن طرح کلان، درخواست فرمها و گردشکارهای پیچیده و کاملاً سفارشی میکند. این درخواستها اغلب بدون تحلیل نیاز واقعی و تنها بر اساس خواسته یک فرد مطرح میشوند. نتیجه، مجموعهای درهم و برهم از فرمهایی است که با هم ارتباطی ندارند، دادهها را به شکلهای مختلف و ناسازگار ذخیره میکنند و نگهداری و بهروزرسانی آنها بسیار دشوار میشود.
برای پاسخ به این درخواستهای سفارشی، سازمان ممکن است مجبور به استخدام توسعهدهندگان خارجی یا مشاوران شود. با گذشت زمان، منطق کسبوکار سازمان در دل این کدهای سفارشی و پیچیده گنجانده میشود. این امر یک وابستگی خطرناک ایجاد میکند. اگر آن توسعهدهنده یا شرکت مشاور، سازمان را ترک کند یا قراردادش پایان یابد، سازمان با یک جعبه سیاه عظیم روبرو میشود که هیچکس در داخل، چگونگی کارکرد یا اصلاح آن را نمیداند. بهروزرسانی نسخه اصلی پلتفرم نیز میتواند به دلیل ناسازگاری با این سفارشیسازیها، غیرممکن یا پرریسک شود.
هر بخش با سفارشیسازی محیط خود، در واقع یک جزیره اطلاعاتی جدید و منحصربهفرد ایجاد میکند. دادههای جمعآوریشده توسط فرم سفارشی بخش فروش، ممکن است به هیچ وجه با دادههای بخش مالی ارتباط برقرار نکنند. این امر گزارشگیری جامع و تحلیل دادهها در سطح سازمان را به یک چالش غیرممکن تبدیل میکند. سازمان در عین حال که ادعا میکند از یک پلتفرم واحد استفاده میکند، در عمل دارای دهها پایگاه داده کوچک و جدا از هم است که هیچیک با دیگری سخن نمیگویند.
هر قطعه کد سفارشی یا فرم پیچیده، به یک موجود زنده تبدیل میشود که نیاز به غذا (یعنی پشتیبانی و نگهداری) دارد. با هر تغییر در فرآیندهای کسبوکار، این قطعات باید بهروزرسانی شوند. با تغییر اعضای تیم، باید مستندسازی و آموزش انجام شود. این هزینههای پنهان پشتیبانی، اغلب در ابتدا دیده نمیشوند اما در بلندمدت، میتوانند بودجه فناوری اطلاعات را به طور کامل به خود اختصاص دهند و از سرمایهگذاری روی نوآوریهای دیگر جلوگیری کنند.
سازمان باید یک «کمیته حکمرانی» متشکل از نمایندگان بخشهای مختلف و فناوری اطلاعات تشکیل دهد. هر درخواست سفارشیسازی باید از این فیلتر عبور کند و بر اساس معیارهایی مانند «اهمیت استراتژیک»، «سازگاری با استانداردهای کلی» و «هزینه کل مالکیت» ارزیابی شود. باید اولویت با استفاده از قابلیتهای استاندارد و بدون کدنویسی باشد. اگر سفارشیسازی اجتنابناپذیر است، باید با رعایت اصول مهندسی نرمافزار، مستندسازی کامل و با در نظر گرفتن امکان توسعه داخلی انجام شود. تمرکز باید بر یکپارچگی دادهها و امکان گزارشگیری فراگیر باشد.
وقتی تصمیم به مهاجرت از یک سیستم قدیمی گرفته میشود، اغلب یک اشتباه مرسوم رخ میدهد: انتقال همه دادهها بدون هیچ فیلتر و پالایشی. فایلهای قدیمی و بیاستفاده، نسخههای متعدد، دادههای تست و اطلاعات شخصی کارکنان، همه و همه به سیستم جدید منتقل میشوند. این کار نه تنها فضای ارزشمند سیستم جدید را اشغال میکند، بلکه همان بینظمی و مشکلات سیستم قدیمی را در بستری جدید زنده نگه میدارد. مهاجرت تبدیل به یک کامیون زباله میشود که آشغالهای قدیمی را به حیاط خانه جدید میریزد.
ساختار دادهها در سیستم قدیمی (مثل پوشهبندیها، فیلدها و رابطهها) به ندرت با طراحی سیستم جدید همخوانی دارد. اگر فرآیند مهاجرت فقط بر انتقال محتوای خام متمرکز شود و این ساختارها و رابطههای مهم (مثل ارتباط یک سند با پروژه خاص) حفظ نشود، دادهها در سیستم جدید بیمعنا و غیرقابل استفاده میشوند. کاربران فایلها را پیدا میکنند اما زمینه و ارتباط آن را درک نمیکنند. این امر باعث سردرگمی و کاهش شدید بهرهوری پس از مهاجرت میشود.
مهاجرت یک عملیات حساس است. اگر بدون برنامهریزی دقیق و در اوج زمان کاری انجام شود، میتواند باعث توقف کامل فعالیتها گردد. ممکن است دسترسی کاربران برای مدت طولانی قطع شود یا دادهها به صورت ناقص منتقل شده و کاربرها نتوانند به اطلاعات ضروری دسترسی پیدا کنند. انتخاب زمان نامناسب (مثل پایان ماه مالی یا روزهای پرکار) بدون اطلاعرسانی و آمادهسازی کاربران، اعتماد به سیستم جدید را در همان روزهای اول به طور جبرانناپذیری از بین میبرد.
حتی اگر دادهها به درستی منتقل شوند، کاربران با یک محیط و روش کار کاملاً جدید روبرو هستند. اگر آموزش کافی و پشتیبانی فنی قوی در روزهای اولیه وجود نداشته باشد، احساس ناامیدی و سردرگمی به سرعت همهگیر میشود. کاربران که با سیستم قدیمی خود خو گرفته بودند، به سرعت سیستم جدید را مقصر میدانند و تمایل پیدا میکنند به روشهای قدیمی (مثل ایمیل) بازگردند. این مقاومت در برابر تغییر، میتواند پروژه مهاجرت را با شکست کامل مواجه کند.
مهاجرت موفق یک پروژه است، نه یک رویداد. باید با یک مرحله «پالایش و پاکسازی» در سیستم قدیمی آغاز شود. فقط دادههای ضروری، فعال و دارای ارزش نگهداری بلندمدت باید انتخاب شوند. سپس نقشهای طراحی شود که چگونه ساختارها و رابطههای کلیدی به ساختار جدید ترجمه میشوند. مهاجرت باید در چند فاز و در ساعات غیرکاری انجام گیرد. اما مهمتر از همه، همراهی کاربران است: آموزشهای عملی، ایجاد راهنماهای ساده، تعیین «سفیران تغییر» در هر بخش و پشتیبانی تماموقت در هفتههای اول، برای پذیرش موفق سیستم جدید حیاتی هستند.
یک اشتباه رایج، تعیین «همه» به عنوان مالک یک سایت یا کتابخانه است. این تفکر که مالکیت جمعی باعث مراقبت همه میشود، در عمل نتیجه معکوس دارد. وقتی همه مسئول هستند، در واقع هیچکس مسئول نیست. اگر مشکلی پیش بیاید یا نیاز به تصمیمگیری باشد، همه منتظر میمانند تا دیگری اقدام کند. محتوا به مرور زمان قدیمی میشود، زیرا هیچکس خود را موظف به بهروزرسانی آن نمیداند. این سایتها و کتابخانهها به مکانهایی متروکه تبدیل میشوند که کسی جرأت حذف یا مرتب کردن آنها را ندارد.
وقتی سیستم دچار اختلال میشود، دادهای گم میشود یا دسترسیها به هم میریزد، یک بازی سرزنش آغاز میشود. تیم فناوری اطلاعات، مدیران بخشها و کاربران نهایی، مسئولیت را به گردن یکدیگر میاندازند. مدیران بخشها میگویند: «ما فقط کاربر هستیم، مشکل از سیستم است.» تیم فناوری اطلاعات میگوید: «ما زیرساخت را فراهم کردیم، این کاربران هستند که بیدقت استفاده میکنند.» این فرار از پاسخگویی، حل مسئله را به تأخیر میاندازد و خسارت را افزایش میدهد.
پروژهها به پایان میرسند، کمپینهای موقت تمام میشوند، اما سایتها و محتوای مربوط به آنها اغلب باقی میمانند. این سایتهای «زامبی» که دیگر مالک فعالی ندارند، به فضایی مرده تبدیل میشوند. ممکن است حاوی اطلاعات حساس یا قدیمی باشند که اگر در جستجو ظاهر شوند، گمراهکننده باشند. از طرفی، هیچکس مسئولیت بایگانی یا حذف آنها را بر عهده نمیگیرد. این محتواهای رها شده، به تدریج سیستم را شلوغ و غیرقابل مدیریت میکنند.
وقتی مالک مشخصی وجود ندارد، هر گونه درخواست برای تغییر یا توسعه سیستم در بلاتکلیفی میماند. آیا باید یک بخش جدید اضافه کرد؟ آیا این فرم نیاز به بازطراحی دارد؟ هیچکس حق تصمیمگیری ندارد و هیچکس حاضر نیست ریسک یک تصمیم ممکن است اشتباه را بپذیرد. این امر باعث رکود و از کارافتادگی سیستم میشود. سیستم نمیتواند با نیازهای در حال تغییر سازمان همگام شود و به تدریج منسوخ میگردد.
برای هر سایت، کتابخانه اصلی، لیست حیاتی و حتی فرآیند مهم، باید یک «مالک کسبوکار» مشخص تعیین شود. نام این شخص باید به طور شفاف در صفحه اصلی آن بخش درج گردد. مالک، مسئول سلامت محتوا، تعریف دسترسیهای لازم، بهروزرسانی اطلاعات و تصمیمگیری درباره تغییرات است. همچنین باید یک «مالک فنی» از طرف فناوری اطلاعات برای پشتیبانی زیرساخت وجود داشته باشد. این نقشها باید بخشی از شرح وظایف رسمی افراد باشد و عملکرد آنها مورد بررسی قرار گیرد. برای پروژههای موقت، باید تاریخ انقضا و مالک مسئول برطرف کردن آن تعیین شود.
یکی از سادهترین، اما ویرانگرترین مشکلات، نبود یک قانون روشن برای نامگذاری فایلها و پوشهها است. در نتیجه، هر فردی بر اساس سلیقه خود عمل میکند. برخی تاریخ را در ابتدا میگذارند (۱۴۰۳۰۲۱۵)، برخی در انتها (گزارش-فروش-بهمن)، برخی از نامهای مبهم استفاده میکنند (سند نهایی، سند خیلی مهم، فایل جدید). این آشفتگی، جستجو را غیرممکن میسازد. حتی اگر فایل مورد نظر در سیستم باشد، پیدا کردن آن نیاز به جستجوی بصری و صرف زمان بسیار دارد. نظم ظاهری سیستم نیز کاملاً از بین میرود.
حتی با وجود پوشهبندی مرتب، اگر کاربران آموزش ندیده باشند یا قانونی وجود نداشته باشد، فایلها در هر جایی که فرد در آن لحظه راحت باشد، ذخیره میشوند. گزارش مالی در پوشه مستندات فنی قرار میگیرد و تصاویر مربوط به کمپین بازاریابی در پوشه قراردادهای حقوقی. این کار نه تنها یافتن فایل را دشوار میکند، بلکه میتواند منجر به نقض حریم خصوصی اطلاعات یا حذف تصادفی دادههای مهم شود. این بینظمی ساختاری، اعتماد به سیستم را به شدت تضعیف میکند.
در مستندات متنی مشترک، نبود قراردادهایی برای قالببندی، سبک نوشتار و به ویژه مدیریت نسخهها مشکلساز میشود. یک کاربر ممکن است مستقیماً روی سند اصلی و نهایی تغییرات بزرگی ایجاد کند، در حالی که دیگری منتظر است نسخهای برای بازبینی دریافت کند. نبود استاندارد برای ذخیره پیشنویسها، نظرات و نسخه نهایی، منجر به سردرگمی درباره این میشود که کدام محتوا، معتبر و قابل استناد است.
وقتی نامگذاری و ذخیرهسازی استاندارد نباشد، حافظه سازمانی آسیب میبیند. کارمند جدیدی که به تیم میپیوندد، ساعتها وقت را باید صرف کند تا بفهمد اسناد مهم کجا هستند و نام هر فایل به چه چیزی اشاره دارد. این موضوع بهرهوری را کاهش داده و انتقال دانش را دشوار میسازد. سازمان در خطر از دست دادن دانش ضمنی و وابستگی بیش از حد به افراد خاص قرار میگیرد.
سازمان باید یک دستورالعمل ساده، روشن و اجباری برای نامگذاری و ذخیرهسازی ایجاد کند. این دستورالعمل باید برای همه بخشها یکسان و شامل مواردی مانند: قالب تاریخ (مثلاً ۱۴۰۳-۰۲-۱۵)، ساختار نام فایل (مثلاً [موضوع]-[تاریخ]-[نگارنده]) و نقشه محل ذخیره انواع مستندات باشد. این قوانین باید در قالب برچسب در خود سیستم، راهنماهای تصویری و دورههای آموزشی کوتاه به همه کاربران منتقل شود. رعایت آن باید بخشی از فرهنگ سازمانی شود و توسط مالکان محتوا نظارت گردد.
همچنین بخوانید: امنیت شیرپوینت: قلعهای غیرقابل نفوذ
یکی از قابلیتهای مفید این سیستمها، امکان آگاهیرسانی خودکار است. اما وقتی هر تغییر کوچکی—از ویرایش یک جمله تا افزودن یک نظر—منجر به ارسال اعلان یا ایمیل شود، کاربر در دریایی از هشدارها غرق میشود. مهمترین اطلاعیهها در میان این سیل گم میشوند. کاربران به مرور زمان همه اعلانها را نادیده میگیرند یا اشتراکها را قطع میکنند و در نتیجه از اطلاعیههای ضروری نیز محروم میمانند. این امر هدف اصلی قابلیت آگاهیرسانی را کاملاً خنثی میکند.
به دلیل پیچیدگی یا کندی رابط کاربری سیستم، بسیاری از کاربران ترجیح میدهند اعلانهای ایمیل را دریافت کنند و مستقیماً از داخل ایمیل خود به محتوا پاسخ دهند یا آن را تأیید کنند. این کار گرچه در کوتاهمدت راحت به نظر میرسد، اما در بلندمدت باعث میشود کاربران هرگز به محیط اصلی سیستم عادت نکنند و درک درستی از گردش کار، تاریخچه تغییرات و محتوای مرتبط پیدا نکنند. سیستم به یک فرستنده ایمیل تقلیل مییابد و سرمایهگذاری روی آن بیثمر میماند.
صدای بیامان هشدارهای سیستم، باز شدن مداوم پنجرههای اعلان و لیست بیپایان ایمیلهای مرتبط با سیستم، تمرکز کاربران را به طور مداوم قطع میکند. این حالت «حواسپرتی دیجیتال» عمیقاً بر کیفیت کار و توانایی تفکر متمرکز تأثیر منفی میگذارد. افراد به جای پرداختن به کار اصلی، دائماً در حال عکسالعمل نشان دادن به محرکهای خارجی هستند که بسیاری از آنها ضروری نیستند.
وقتی یک وظیفه حیاتی یا درخواست تأییدیه فوری در کنار دهها اعلان معمولی دیگر ارسال شود، احتمال نادیده گرفته شدن آن بسیار بالا میرود. این موضوع میتواند موجب تأخیر در تصمیمگیریهای مهم، از دست دادن مهلتهای قانونی یا تاخیر در چرخه پرداخت شود. نبود سیستم اولویتبندی در اعلانها، یکی از ضعفهای بزرگ است که میتواند عواقب عملیاتی جدی به دنبال داشته باشد.
باید یک سیاست مرکزی برای تنظیم اعلانها تعریف شود. به طور پیشفرض، اشتراکگذاری باید خاموش باشد و تنها برای رویدادهای بسیار مهم (مانند ایجاد یک سند حیاتی، اتمام یک فرآیند یا درخواست تأییدیه با مهلت مشخص) فعال گردد. کاربران باید آموزش ببینند که چگونه به صورت انتخابی برای موارد ضروری اشتراک فعال کنند. همچنین، باید کانالهای ارتباطی متفاوتی برای اطلاعرسانیهای فوری (مانند پیامرسانهای تیمی) و تعاملات بلندمدتتر (خود سیستم) تعریف شود تا بار شناختی کاربران کاهش یابد.
پیچیدگی ظاهری و عمق امکانات این پلتفرمها اغلب برای کاربر عادی که کار اصلی غیرفنی دارد، ترسناک است. اگر سازمان سرمایهگذاری مناسبی روی آموزش ساده، مکرر و عملی نکند، یک شکاف بزرگ بین آنچه سیستم میتواند انجام دهد و آنچه کاربران واقعاً از آن استفاده میکنند، به وجود میآید. در نتیجه، تنها از ۱۰ درصد قابلیتهای سیستم استفاده میشود و ارزش واقعی آن محقق نمیگردد. کاربران در سطح ابتدایی باقی میمانند و از قدرت واقعی ابزار بیخبرند.
انسانها به طور طبیعی در برابر تغییر مقاومت میکنند. اگر مزایای سیستم جدید به وضوح نشان داده نشود و دردسر یادگیری آن بیشتر از منافعش به نظر برسد، کاربران به روشهای قدیمی و ناکارآمد خود بازمیگردند. آنها دوباره از ایمیل برای ارسال فایلهای حجیم استفاده میکنند، گزارشها را روی درایوهای شخصی ذخیره میکنند و گردش کارها را به صورت دستی و مبتنی بر کاغذ پیش میبرند. این مقاومت، پروژه را از درون خالی میکند.
اگر محیطی سختگیرانه و بدون پشتیبانی ایجاد شود، کاربران از انجام هر کاری به جز سادهترین عملیات میترسند. ترس از پاک کردن اشتباهی دادهها، به هم ریختن ساختار سایت یا مسدود کردن یک گردش کار، باعث میشود افراد کاملاً منفعل شوند. این فرهنگ ترس، خلاقیت و ابتکار عمل برای بهینهسازی فرآیندها با استفاده از ابزار را کاملاً از بین میبرد. سیستم به جای یک تسهیلگر، به یک منبع اضطراب تبدیل میشود.
در غیاب آموزش مناسب، تیم فناوری اطلاعات به جای تمرکز بر مدیریت استراتژیک سیستم، غرق در پاسخگویی به سوالات ساده و رفع مشکلات ابتدایی کاربران میشود. این پشتیبانی سطح اول که باید از طریق راهنماها، آموزشهای خودآموز یا سفیران بخشها انجام شود، به طور کامل بر دوش متخصصان فنی میافتد و آنها را از مأموریت اصلی خود بازمیدارد.
آموزش نباید یک رویداد یکباره در ابتدای راهاندازی باشد. باید یک برنامه آموزشی مداوم و چندسطحی وجود داشته باشد: آموزش اولیه برای همه، آموزشهای پیشرفته اختیاری برای علاقهمندان، و آموزشهای تخصصی برای مالکان محتوا و مدیران. محتوای آموزشی باید بر اساس وظایف روزمره کاربران و به زبان ساده باشد. ایجاد شبکهای از «سفیران دیجیتال» در هر بخش که همکاران خود را راهنمایی کنند، بسیار مؤثر است. همچنین، برجسته کردن و تقدیر از «موفقیتهای کوچک» کاربران در استفاده از سیستم، انگیزه ایجاد میکند.
با گذشت زمان، کل فرآیندهای حیاتی سازمان، ارتباطات، مستندات و دادههای عملیاتی در دل این سیستم ذخیره و اجرا میشوند. سیستم به شریان اصلی کسبوکار تبدیل میشود. این وابستگی عمیق یک خطر استراتژیک بزرگ ایجاد میکند. اگر به هر دلیلی (مثلاً تغییر سیاستهای فروشنده، افزایش نجومی هزینههای مجوز یا مشکلات فنی پایدار) سازمان نیاز به تعویض پلتفرم داشته باشد، خروج به یک عملیات تقریباً غیرممکن، پرخطر و فوقالعاده پرهزینه تبدیل میشود. دادهها و فرآیندها در سیستم فعلی «قفل» شدهاند.
هزینه این سیستمها تنها به مجوزهای کاربری ختم نمیشود. با رشد دادهها، نیاز به فضای ذخیرهسازی، قدرت پردازش و پهنای باند شبکه افزایش مییابد. هزینههای پشتیبانی، توسعه سفارشی و ادغام با سیستمهای دیگر نیز به صورت پیوسته اضافه میشوند. این هزینههای تدریجی و پنهان میتوانند در بلندمدت از کنترل خارج شوند و توجیه اقتصادی اولیه پروژه را زیر سؤال ببرند، اما به دلیل وابستگی ایجادشده، امکان توقف وجود ندارد.
تمرکز همه چیز در یک سبد، ریسک را افزایش میدهد. یک حمله سایبری موفق، یک باگ نرمافزاری بحرانی یا یک اشتباه پیکربندی میتواند کل سیستم و در نتیجه کل عملیات سازمان را فلج کند. اگر طرح احیا و تداوم کسبوکار به درستی طراحی نشده باشد، این وابستگی مطلق میتواند منجر به توقف طولانیمدت فعالیتها و خسارات جبرانناپذیر مالی و اعتباری گردد.
توسعهدهندگان اصلی این پلتفرمها، چرخه بهروزرسانی و نوآوری خود را دارند. ممکن است سازمانی نیازمند قابلیت خاصی باشد که در اولویت توسعه فروشنده نیست. به دلیل وابستگی زیاد و هزینه بالای تغییر، سازمان در استفاده از فناوریهای نوظهور و چابکتر که میتوانند مزیت رقابتی ایجاد کنند، ناتوان میشود. سازمان اسیر مسیر تحول از پیش تعیینشده توسط یک فروشنده خاص میگردد.
از همان ابتدا باید با در نظر گرفتن امکان خروج، طراحی انجام شود. این شامل خودداری از قفل شدن در قابلیتهای کاملاً انحصاری یک فروشنده، استفاده از استانداردهای باز برای ذخیره دادهها و مستندسازی کامل فرآیندها و سفارشیسازیها است. باید یک «استراتژی خروج» رسمی شامل روشهای استخراج دادهها و انتقال آنها به قالبهای استاندارد، تدوین شود. همچنین، مدیریت چرخه حیات سیستم—با بررسی دورهای توجیه اقتصادی، ریسکها و هماهنگی آن با اهداف استراتژیک کسبوکار—اجتنابناپذیر است. وابستگی باید هوشمندانه و با چشمان باز مدیریت شود.
پاسخ: بزرگترین اشتباه، شروع استفاده بدون برنامهریزی و معماری اطلاعات است. هنگامی که ساختار پوشهها، دستهبندیها، سطوح دسترسی و فرآیندهای تایید از ابتدا تعریف نشوند، بینظمی به سرعت همهجا را فرا میگیرد.
پاسخ: با ایجاد یک “منبع حقیقت واحد” برای هر نوع سند یا اطلاعات. همه باید بدانند که آخرین نسخه قالب قرارداد، فرم درخواست مرخصی یا گزارش مالی در کجا و فقط در یک محل مشخص ذخیره میشود. استفاده از قابلیت پیوند به فایلها به جای کپی کردن آنها نیز کمککننده است.
پاسخ: خیر، در بسیاری از موارد کندی سیستم ناشی از طراحی ضعیف است. ایجاد لیستها یا کتابخانههای عظیم با هزاران آیتم در یک صفحه، استفاده نادرست از ستونهای محاسباتی سنگین و ذخیره مستقیم فایلهای حجیم (به جای پیوند به آرشیو) میتواند باعث افت شدید عملکرد شود.
پاسخ: کاربران با رعایت انضباط شخصی نقش کلیدی دارند. این شامل نامگذاری صحیح فایلها، قرار دادن آنها در محل تعیینشده، درخواست دسترسی فقط به موارد مورد نیاز و شرکت در دورههای آموزش اولیه میشود. یک کاربر آگاه، بهترین محافظ در برابر هرجومرج است.
پاسخ: بله، اما نیاز به یک تلاش سازمانیافته دارد. باید پروژه کوچکی برای “بازسازی و نظمبخشی” تعریف کرد. این کار شامل ممیزی محتوا، پاکسازی دادههای بلااستفاده و تکراری، بازتعریف ساختار بر اساس نیازهای واقعی و آموزش مجدد کاربران است. بهتر است این کار با کمک یک مشاور مجرب انجام شود.
پروژههای مدیریت محتوا با استفاده از پلتفرمهای گروهی، پتانسیل بسیار بالایی برای بهبود همکاری و نظمبخشی به اطلاعات دارند. اما این پتانسیل تنها زمانی به واقعیت میپیوندد که از ابتدا با برنامهریزی، آموزش و معماری درست آغاز شود. تجربه نشان داده است که غفلت از اصول اولیه طراحی، تعریف نقشها و فرآیندهای نظارتی، میتواند به سرعت پروژهای به ظاهر ساده را به یک غول پیچیده و غیرقابل کنترل تبدیل کند.
مواجهه با انبوهی از دادههای تکراری و ناسازگار، از دست دادن کنترل نسخههای مختلف اسناد، افت شدید عملکرد به دلیل پیچیدگی رابط کاربری و مشکلات امنیتی ناشی از تنظیمات نادرست، تنها بخشی از کابوسهای رایج هستند.
کلید موفقیت، پرهیز از شتابزدگی در مرحله اجرا و اختصاص زمان کافی برای تحلیل نیازها، طراحی ساختار اطلاعات، آموزش کاربران نهایی و تعیین مالکهای مشخص برای هر بخش است. مدیریت این پلتفرمها یک فرآیند مستمر است، نه یک پروژه یکباره. با نگاهی پیشگیرانه، تعهد مدیریت و درک صحیح از ابزار، میتوان از تبدیل شدن این سیستمهای قدرتمند به داستانهای ترسناک اداری جلوگیری کرد و در عوض، از مزایای واقعی آنها برای تحول دیجیتال سازمان بهرهمند شد.
برای مطالعه بیشتر درباره بهترین روشهای طراحی و معماری اطلاعات در اینگونه پلتفرمها که میتواند از بروز بسیاری از این مشکلات جلوگیری کند، پیشنهاد میکنیم مقاله جامع “اصول طراحی ساختار اطلاعات در سیستمهای مدیریت محتوای سازمانی” را در وبسایت معتبر انجمن مدیریت اطلاعات مطالعه نمایید. (لینک: https://www.aiim.org/What-is-Information-Architecture)
در خبرنامه ما مشترک شوید و آخرین اخبار و به روزرسانی های را در صندوق ورودی خود مستقیماً دریافت کنید.

دیدگاه بگذارید