07
مهبسیاری از سازمانها تصمیم به راهاندازی شیرپوینت میگیرند، تنها به این دلیل که نام آن را شنیدهاند یا رقبای آنها از آن استفاده میکنند. در این شرایط، هیچ پاسخ روشنی برای سوال “چرا شیرپوینت؟” وجود ندارد. آیا هدف جایگزینی درایوهای شبکه است؟ بهبود مدیریت اسناد پروژهها است؟ یا خودکارسازی فرآیندهای اداری؟ وقتی هدف اصلی از ابتدا شفاف نباشد، تمام مراحل بعدی بر اساس حدس و گمان پیش میرود. در نهایت، سیستمی پیادهسازی میشود که با نیازهای واقعی سازمان همخوانی ندارد. این نبود چشمانداز، باعث سردرگمی مدیران و کاربران شده و سرمایهگذاری انجام شده را به خطر میاندازد. سازمان باید پیش از هر اقدامی، مشکلات فعلی خود را شناسایی و مشخص کند که انتظار دارد شیرپوینت چه گرههایی را بگشاید.
پس از تعیین هدف، نوبت به طراحی نقشه راه میرسد. متأسفانه، در بسیاری از موارد، سازمانها فکر میکنند با خرید مجوز و نصب شیرپوینت، کار به پایان رسیده است. آنها برنامهای برای فازبندی اجرا، زمانبندی آموزش کاربران، تعیین معیارهای موفقیت و بررسی دورهای نتایج ندارند. این عدم برنامهریزی منجر به شتابزدگی در اجرا یا بلاتکلیفی میشود. ممکن است تمام بخشها به یکباره به سیستم دسترسی پیدا کنند، بدون اینکه آمادگی لازم را داشته باشند. یا پروژه ماهها نیمهکاره رها شود. یک برنامه اجرایی منسجم، گامهای کوچک و قابل مدیریت را تعریف میکند و احتمال موفقیت را به شدت افزایش میدهد.
ذینفعان اصلی شیرپوینت، کاربران نهایی آن هستند؛ یعنی همان کارمندان بخشهای مختلف. یک اشتباه رایج این است که فقط مدیران فناوری اطلاعات یا یک مشاور خارجی، در مورد ساختار و امکانات سیستم تصمیمگیری میکنند. آنها بدون گفتگو با تیم مالی، منابع انسانی، فروش یا عملیات، ساختاری را پیاده میکنند که ممکن است از نظر فنی بینقص، اما از نظر کاربردی کاملاً نامربوط باشد. برای مثال، ممکن است نیاز اصلی بخش فروش، داشتن یک سایت برای مدیریت پیشنهادها باشد، اما سیستم پیادهشده بر روی مخزن اسناد عمومی متمرکز است. تحلیل نیازها، تضمین میکند که سیستم به حل واقعیترین مشکلات کاربران میپردازد.
چگونه متوجه شویم که پیادهسازی شیرپوینت موفق بوده است؟ اگر سازمان نتواند از ابتدا شاخصهای قابل اندازهگیری برای موفقیت تعریف کند، هرگز نمیتواند نتیجه کار را ارزیابی نماید. این شاخصها میتوانند کیفی (مانند رضایت کاربران) یا کمی (مانند کاهش زمان تأیید یک فرم، کاهش حجم ایمیلهای داخلی، یا افزایش دسترسی به آخرین نسخه اسناد) باشند. عدم وجود این معیارها باعث میشود پروژه در بلاتکلیفی ادامه یابد و نتوان نقاط قوت و ضعف آن را به درستی شناسایی و بهبود بخشید.
برخی از مدیران با دیدن قابلیتهای تبلیغاتی شیرپوینت، تصور میکنند این سیستم به تنهایی و به طور خودکار، تمام مشکلات ارتباطی، مدیریتی و فرآیندی سازمان را حل خواهد کرد. آنها انتظار دارند بدون سرمایهگذاری کافی روی آموزش، تغییر فرآیندها و مدیریت تغییر، معجزهای رخ دهد. این نگرش منجر به ناامیدی سریع میشود. وقتی سیستم به طور جادویی همه چیز را درست نمیکند، کل پروژه محکوم به شکست تلقی شده و کنار گذاشته میشود. درک این نکته ضروری است که شیرپوینت یک تقویتکننده است، نه یک جایگزین برای مدیریت خوب، فرآیندهای شفاف و فرهنگ همکاری.
همچنین بخوانید: طراحی داشبورد روزانه در شیرپیونت ؛ از ایده تا اجرا
یکی از رایجترین اشتباهات در شروع کار، تلاش برای بازسازی کامل چارت سازمانی در قالب سایتهای شیرپوینت است. سازمانها برای هر بخش، هر واحد، هر پروژه و هر کمیته، یک سایت مجزا ایجاد میکنند. این کار در ابتدا منظم به نظر میرسد، اما به سرعت به یک جنگل غیرقابل مدیریت تبدیل میشود. کاربران برای یافتن یک سند ساده، باید بین دهها سایت مختلف جستجو کنند. مدیریت دسترسیها در این ساختار به کابوسی امنیتی بدل میشود و به روزرسانیهای کلان بسیار دشوار میگردد. این پیچیدگی غیرضروری، بزرگترین مانع برای پذیرش سیستم توسط کاربران عادی است.
وقتی ساختار پیچیده باشد، نامگذاری سایتها، کتابخانهها و پوشهها نیز اغلب آشفته خواهد بود. نبود یک استاندارد واحد برای نامگذاری، منجر به ایجاد اسامی تکراری، مبهم یا شخصیسازی شده میشود. برای مثال، ممکن است یک کتابخانه “اسناد” در یک سایت، حاوی قراردادها باشد و در سایت دیگر، گزارشهای ماهانه. یا کاربران برای ذخیره یک نوع سند، از نامهای متفاوتی مانند “پروپوزال”، “پیشنهاد” یا “Offer” استفاده کنند. این بینظمی، قابلیت جستجو را عملاً از بین میبرد و یافتن اطلاعات را به یک فرآیند وقتگیر و مبتنی بر شانس تبدیل میکند.
برخی مدیران سیستم، عادت قدیمی مدیریت فایل در ویندوز را به شیرپوینت منتقل میکنند و عمیقترین ساختارهای پوشهای ممکن را میسازند. یک سند ممکن است در مسیری مانند: سایت بخش فروش > کتابخانه “مستندات” > پوشه “سال1403” > پوشه “مشتریان” > پوشه “شرکت الف” > پوشه “قراردادها” > پوشه “نسخه نهایی” ذخیره شود. این ساختار نه تنها دسترسی را دشوار میکند، بلکه بسیاری از قابلیتهای مدرن شیرپینوت مانند نمایشهای مختلف، فیلترهای پویا و متادیتا (اطلاعات توصیفی) را بیاثر میسازد. در محیطهای همکاری مدرن، تاکید بر استفاده از “برچسبگذاری” و “جستجو” به جای “پوشهبندی” است.
هدف نهایی، ایجاد سیستمی است که مردم بتوانند به راحتی از آن استفاده کنند. اما در بسیاری از طراحیها، معیارهای فنی یا اداری بر نیازهای کاربران اولویت پیدا میکند. ساختاری ایجاد میشود که از نظر مدیر فناوری اطلاعات منطقی است، اما برای یک کارمند بازاریابی یا مالی کاملاً نامفهوم است. عدم در نظر گرفتن تجربه کاربری، منجر به ایجاد موانع روانی برای استفاده از سیستم میشود. کاربران یا از سیستم فرار میکنند و به ایمیل و درایوهای قدیمی بازمیگردند، یا با بیدقتی و اکراه از آن استفاده میکنند که خود باعث تخریب کیفیت دادهها میشود.
ساختاری که امروز برای 50 کاربر و 1000 سند مناسب است، ممکن است فردا با رشد سازمان، 500 کاربر و 100000 سند را پشتیبانی نکند. یک تصمیم سازمانی کوتاهبینانه، طراحی ساختاری است که فقط نیازهای فعلی را در نظر میگیرد و هیچ راهکاری برای توسعه منسجم در آینده ندارد. این باعث میشود پس از چند سال، سازمان مجبور به مهاجرت دردناک به یک ساختار جدید یا ادامه کار با سیستمی بسیار کند و ناکارآمد شود. یک طراحی حرفهای، از همان ابتدا “مقیاسپذیری” و امکان ادغام با سیستمهای دیگر را در نظر میگیرد.
یک فرض خطرناک و رایج در سازمانها این است که فکر میکنند چون شیرپوینت یک محصول مایکروسافت و دارای آیکونها و منوهای آشناست، نیازی به آموزش خاصی ندارد. آنها تصور میکنند کاربران به طور شهودی میتوانند با آن کار کنند. این باور کاملاً نادرست است. فلسفه کاری، مفاهیم همکاری، مدیریت نسخهها، تفاوت سایت و کتابخانه، و روشهای جستجوی مؤثر، همگی نیازمند آموزش اختصاصی هستند. بدون این آموزش، کاربران تنها عملکردهای بسیار ابتدایی را کشف میکنند و هرگز به قدرت واقعی پلتفرم پی نمیبرند.
حتی سازمانهایی که آموزش ارائه میدهند، اغلب مرتکب این اشتباه میشوند که یک آموزش عمومی و تئوری برای تمام کارکنان ترتیب میدهند. در این جلسات، مربی تمام ویژگیهای شیرپوینت را به صورت فهرستوار نشان میدهد، بدون اینکه ارتباط آن را با کار واقعی هر بخش نشان دهد. یک حسابدار نحوه مدیریت یک کتابخانه اسناد پروژه مهندسی را میآموزد که هرگز با آن سر و کار نخواهد داشت. این نوع آموزش، وقتگیر و بیفایده است. کاربران به سرعت مطالب را فراموش میکنند چون نیاز فوری به استفاده از آنها ندارند.
آموزش نباید محدود به یک یا دو جلسه در ابتدای کار باشد. با گذشت زمان، سوالات جدید مطرح میشود، کاربران پیشرفتهتر میشوند و نیاز به یادگیری قابلیتهای پیچیدهتر پیدا میکنند. اگر سازمان منابعی مانند ویدیوهای کوتاه آموزشی، راهنمای تصویری داخلی، یا یک تیم پشتیبانی فنی پاسخگو ایجاد نکند، کاربران در مواجهه با اولین مشکل، دلسرد میشوند. آنها یا از سیستم استفاده نادرست میکنند (مثلاً با آپلود هزاران فایل در یک پوشه) یا به کلی آن را رها میکنند. آموزش باید یک فرآیند مستمر و در دسترس باشد.
تغییر همیشه با مقاومت همراه است. بسیاری از کارکنان، به ویژه آنهایی که سالها با روشهای قدیمی کار کردهاند، از سیستم جدید میترسند. آنها نگران هستند که نتوانند از عهده آن برآیند، اشتباه کنند، یا زمان زیادی را برای یادگیری تلف کنند. یک تصمیم مدیریتی نادرست، نادیده گرفتن این ترسها و اجبار محض برای استفاده از سیستم است. این اجبار تنها مقاومت را افزایش میدهد و یک حس منفی نسبت به شیرپوینت ایجاد میکند. مدیریت باید این ترس را به رسمیت بشناسد و با نشان دادن مزایای ملموس (مثل صرفهجویی در زمان)، آن را کاهش دهد.
موثرترین روش برای انتشار فرهنگ استفاده صحیح، شناسایی و آموزش افرادی در هر بخش است که به فناوری علاقهمندند و توسط همکاران خود مورد احترام هستند. این افراد “سفیران شیرپوینت” میشوند. آنها میتوانند به همتیمیهای خود کمک فوری و مرتبط ارائه دهند، ایدههای بهبود را جمعآوری کنند و بازخوردها را به تیم مرکزی منتقل کنند. اگر سازمان این شبکه ارتباطی غیررسمی اما قدرتمند را ایجاد نکند، تمام بار آموزش و پشتیبانی بر دوش گروه فناوری اطلاعات خواهد افتاد که اغلب از جزئیات کاری هر بخش بیاطلاع است.
به دلایلی مانند عجله در راهاندازی یا نبود نیروی متخصص، سازمانها ممکن است دسترسی سطح مدیر سیستم را به چندین نفر در بخشهای مختلف بدهند. این تصمیم فاجعهبار است. این افراد میتوانند به طور ناخواسته یا از روی کنجکاوی، ساختار اصلی را تغییر دهند، سایتهای حذفنشدنی ایجاد کنند، یا تنظیمات امنیتی را به هم بریزند. هرچه تعداد مدیران سیستم بیشتر باشد، احتمال بروز خطا، ناهماهنگی و آسیبپذیری امنیتی بیشتر میشود. دسترسی مدیریتی باید محدود به یک یا دو نفر بسیار آموزشدیده و مسئول باشد.
سادهترین راه برای تنظیم دسترسی، دادن دسترسی “خواندن” یا “ویرایش” به گروه “همه کاربران” است. این کار در کوتاهمدت مشکل را حل میکند، اما در بلندمدت فاجعهآفرین است. به این معنی است که هر فرد جدیدی که به سازمان میپیوندد، به طور خودکار به حجم عظیمی از اطلاعات حساس دسترسی پیدا میکند. همچنین، امکان مدیریت دقیق محتوای اختصاصی از بین میرود. سازمان باید برای گروههای کاری مختلف (مثل “تیم مالی”، “مدیران پروژه”، “کارکنان قراردادی”) گروههای امنیتی تعریف کند و دسترسیها را به دقت بر اساس نقش افراد تنظیم نماید.
در نقطه مقابل، برخی سازمانها آنقدر در جزئیات غرق میشوند که برای هر سایت کوچک، گروههای امنیتی جدیدی مانند “اعضای سایت پروژه X”، “ویراستاران سایت پروژه X” و “بازبینهای سایت پروژه X” میسازند. پس از چند ماه، صدها گروه امنیتی غیرقابل مدیریت ایجاد شده است. وقتی فردی تغییر نقش دهد، باید عضویت او را در دهها گروه به صورت دستی بررسی و تغییر داد. این کار بسیار خطاپذیر و زمانبر است. بهترین روش، استفاده از گروههای امنیتی کلی سازمان (مبتنی on دپارتمان یا نقش) و ترکیب آنها با گروههای اختصاصی سایت تنها در صورت لزوم است.
دسترسیها ثابت نمیمانند. افراد تغییر شغل میدهند، پروژهها پایان مییابند، پیمانکاران میروند. اگر فرآیندی برای بررسی منظم و حذف دسترسیهای منقضیشده وجود نداشته باشد، سیستم به مرور زمان ناامن میشود. افرادی که سال پیش در پروژهای مشارکت داشتند، ممکن است هنوز به اسناد محرمانه آن دسترسی داشته باشند. این یک ریسک امنیتی و Compliance (انطباق) بزرگ است. سازمان باید تصمیم بگیرد که هر شش ماه یا یک سال، مدیران هر بخش تأیید کنند که چه کسانی باید به سایتهای تحت مدیریتشان دسترسی داشته باشند.
بعضی سازمانها، از ترس بینظمی، دکمه “سایت جدید” را از همه کاربران میگیرند و هر درخواستی باید از طریق بخش فناوری اطلاعات و با تأیید چند مدیر انجام شود. این تصمیم اگرچه نظم را حفظ میکند، اما شیرپوینت را از یک ابزار پویای همکاری به یک سیستم ایستا و بوروکراتیک تبدیل میکند. گاهی یک تیم برای یک کار کوتاهمدت به فضای همکاری سریع نیاز دارد، اما به دلیل فرآیند طولانی درخواست، از سیستم صرف نظر میکنند. تعادل کلید موفقیت است: میتوان به گروههای معتمدی اجازه داد سایتهای تیمی موقت ایجاد کنند، در حالی که سایتهای رسمی و دپارتمانی با نظارت بیشتری ساخته شوند.
این یک سوءتفاهم ریشهای است. نقش بخش فناوری اطلاعات، راهاندازی، حفظ امنیت، پشتیبانگیری و در دسترس نگه داشتن پلتفرم شیرپوینت است. اما آنها مسئول محتوای داخل سایتها نیستند. آنها نمیدانند که کدام سند قدیمی را باید حذف کرد، چه کسی باید یک فرم جدید را تأیید کند، یا ساختار یک کتابخانه خاص چگونه باید باشد. وقتی سازمان به طور ضمنی فناوری اطلاعات را مسئول محتوا بداند، هم کارکنان این بخش تحت فشار کاری غیرمرتبط قرار میگیرند و هم کیفیت محتوا افت میکند، زیرا متولی واقعی ندارد.
هر سایت یا کتابخانه مهم باید یک “مالک” یا “مدیر محتوا” داشته باشد. این شخص معمولاً از بین کاربران فعال همان بخش انتخاب میشود و مسئول نظارت بر نظم، تمیزی و روزآمدی محتوای آن فضا است. اگر چنین فردی تعیین نشود، سایت به مرور به انباری از فایلهای قدیمی، تکراری و بینام و نشان تبدیل میشود. هیچ کس احساس مسئولیت نمیکند که فایلهای تستی را پاک کند، پوشههای جدید ایجاد نماید یا کاربران جدید را اضافه کند. تصمیم نکردن درباره مالکیت، مساوی با رها کردن سیستم به حال خود است.
مدیریت موفق شیرپوینت بر پایه “عدم تمرکز” است. کاربران هر بخش بهتر از هر کس دیگری میدانند محتوای آنها چگونه باید سازماندهی شود. یک تصمیم سازمانی نادرست، متمرکز کردن تمام قدرت در دست یک تیم کوچک است. این تیم به زودی به گلوگاه تبدیل میشود. تمام درخواستهای کوچک (ایجاد یک ستون جدید در لیست، تغییر یک دسترسی ساده، ساخت یک فرم) در صفی طولانی معطل میمانند و از کارایی سیستم کاسته میشود. باید به کاربران آموزش داده شود و سپس مسئولیت کارهای روزمره سایت خود را به آنها سپرد.
پروژهها تمام میشوند، اما سایتهای شیرپوینت آنها اغلب تا ابد باقی میمانند. هیچکس تصمیم نمیگیرد که با این سایتهای تاریخی چه کار کند. آیا باید بایگانی شوند؟ آیا محتوای مهم آنها به یک سایت مرکزی منتقل و سپس سایت حذف شود؟ نبود یک خطمشی روشن برای “چرخه حیات سایت”، منجر به انباشته شدن صدها سایت غیرفعال میشود. این موضوع، فضای ذخیرهسازی را هدر میدهد، نتایج جستجو را آلوده میکند و مدیریت کل مجموعه را پیچیده میکند. باید از ابتدا مشخص شود که پس از پایان یک پروژه، مالک سایت موظف است ظرف مدت معینی آن را بایگانی یا حذف کند.
حتی اگر مالکانی برای سایتها تعیین شوند، اگر از آنها بازخواست نشود و عملکرد سایتهایشان بررسی نگردد، این عنوان تنها یک اسم بیمسمی خواهد بود. سازمان باید شاخصهای سادهای را برای ارزیابی سلامت سایتها تعریف کند؛ مانند تاریخ آخرین بهروزرسانی، تعداد اسناد قدیمی (مثلاً بیش از 3 سال)، یا تعداد کاربران فعال. این گزارشها باید به طور دورهای با مالکان سایت مرور شود. این کار فرهنگ مسئولیتپذیری و مراقبت از داراییهای اطلاعاتی مشترک را نهادینه میکند.
شیرپوینت جعبه ابزار بزرگی است با قابلیتهای فراوان و امکان توسعهپذیری بالا. یک تصمیم نادرست سازمانی، تلاش برای پیادهسازی همه این قابلیتها به صورت سفارشی از همان روز اول است. ممکن است سازمان بودجه زیادی صرف توسعه یک پورتال پیچیده، فرمهای سفارشی سنگین یا گردش کارهای چندمرحلهای کند، در حالی که کاربران هنوز در آپلود ساده یک فایل مشکل دارند. این سفارشیسازیهای زودهنگام و غیرضروری، نه تنها هزینهبر است، بلکه سیستم را شکننده میکند و ارتقا به نسخههای جدید را بسیار دشوار میسازد.
در نقطه مقابل سفارشیسازی افراطی، سازمانها گاهی از ترس پیچیدگی، به سراغ قابلیتهای قدرتمند اما استاندارد شیرپوینت نمیروند. برای مثال، به جای استفاده از “لیستها” برای پیگیری وظایف یا درخواستها، از فایلهای اکسل در یک پوشه استفاده میکنند. یا به جای به کارگیری “گردش کار” ساده برای اطلاعرسانی و تأیید، فرآیند را به صورت دستی و از طریق ایمیل انجام میدهند. این تصمیم باعث میشود از مزایای اصلی شیرپوینت در خودکارسازی و مرکزیکردن اطلاعات استفاده نشود و سیستم تنها به یک حافظه ابری ساده تنزل یابد.
سازمانها ممکن است تصمیم بگیرند شیرپوینت را با نرمافزارهای مالی، منابع انسانی یا CRM خود یکپارچه کنند. اگر این کار بدون تحلیل دقیق، طراحی فنی مناسب و در نظر گرفتن امنیت دادهها انجام شود، فاجعهآفرین خواهد بود. ممکن است این یکپارچهسازی ناپایدار باشد، باعث کندی سیستم شود، یا حفرهای امنیتی ایجاد کند. تصمیم برای یکپارچهسازی باید مبتنی بر یک نیاز تجاری قوی و با همراهی متخصصان هر دو سیستم باشد، نه بر اساس هیجان و مد روز.
هر قابلیت اضافه یا سفارشیسازی، علاوه بر هزینه اولیه توسعه، هزینه مستمر نگهداری دارد. با هر بروزرسانی شیرپوینت، ممکن است آن قابلیت سفارشی از کار بیفتد و نیاز به اصلاح داشته باشد. سازمانهایی که بدون محاسبه این هزینه بلندمدت، اقدام به افزودن امکانات میکنند، پس از مدتی متوجه میشوند که بودجه و نیروی کافی برای نگهداری از تمام این توسعهها را ندارند. در نتیجه سیستم ناپایدار شده یا بخشی از قابلیتها غیرفعال میماند و اعتماد کاربران را از بین میبرد.
گاهی اوقات، به دلیل ناآگاهی یا بیصبری یک بخش، زمانی که درخواست آنها برای یک قابلیت خاص به سرعت توسط تیم مرکزی پاسخ داده نمیشود، آن بخش خود به صورت جداگانه یک لیست یا یک برنامه کاربردی دیگر را در شیرپوینت راه میاندازد که همان کار سیستم اصلی را میکند. این تصمیم، منجر به ایجاد چندین منبع حقیقت میشود. دادهها بین این سیستمهای موازی ناسازگار میشوند و هیچکس نمیداند کدام یک معتبر است. سازمان باید یک راهحل متمرکز و مورد توافق همه ارائه دهد و از ایجاد تلاقیهای اطلاعاتی جلوگیری کند.
بزرگترین دشمن کارایی شیرپوینت، انباشته شدن فایلها و صفحاتی است که فاقد اطلاعات توصیفی (متادیتا) هستند. وقتی کاربران یک سند را آپلود میکنند، تنها فیلد اجباری معمولاً “نام فایل” است. اگر سازمان سیاستی برای پر کردن فیلدهای اضافی مانند “نوع سند”، “شماره پروژه”، “تاریخ انقضا” یا “واحد مربوطه” تعیین نکند، تمام محتوا تبدیل به کپهای بیشکل میشود. در این حالت، جستجو تنها بر اساس نام فایل انجام میشود که اگر کاربر نام دقیق را نداند، کاملاً بیفایده است.
صفحه اصلی هر سایت، ویترین و نقشه آن فضای کاری است. یک تصمیم سازمانی کوتاهبینانه، رها کردن طراحی این صفحات یا سپردن آن به افرادی است که دانشی از طراحی کاربرپسند ندارند. ممکن است صفحه با آخرین اخبار بیربط پر شود، یا لیستی بیپایان از پیوندها بدون هیچ دستهبندی منطقی ارائه گردد. یک صفحه اصلی خوب باید سریعاً کاربر را به مهمترین محتواها، ابزارها و وظایفش راهنمایی کند. غفلت از این موضوع، اولین تجربه کاربر را منفی کرده و حس گمشدگی در سایت را ایجاد مینماید.
موتور جستجوی شیرپوینت بسیار قدرتمند است، اما اگر محتوای آن ساختاریافته نباشد، این قدرت هدر میرود. سازمانها اغلب پس از راهاندازی، هیچ کاری برای بهبود تجربه جستجو انجام نمیدهند. آنها از ویژگیهایی مانند “جستجوی تصحیح شده”، “فیلترهای پویا بر اساس متادیتا”، “نمایش پیشنمایش محتوا” یا “تعیین نتایج برتر” استفاده نمیکنند. در نتیجه، کاربر در برابر هزاران نتیجه بیربط قرار میگیرد و نمیتواند آنچه را نیاز دارد پیدا کند. مدیریت جستجو نیازمند پیکربندی و توجه مداوم است.
یکی از مشکلات اصلی در جستجو، استفاده افراد مختلف از واژههای متفاوت برای یک چیز است. یک بخش ممکن است به “کارمند” بگوید “همکار”، بخش دیگر “پرسنل”. یا اسناد مربوط به “ارزیابی عملکرد” ممکن است با برچسبهای “بازخورد”، “بررسی سالانه” یا “نظرسنجی” ذخیره شده باشند. اگر سازمان برای اصطلاحات کلیدی خود یک واژهنامه استاندارد تعریف و ترویج نکند، موتور جستجو هرگز نمیتواند تمام اسناد مرتبط را یکجا نشان دهد. این استانداردسازی، پایه و اساس یک سیستم اطلاعاتی منسجم است.
حتی با بهترین متادیتاها، اگر اطلاعات مربوط به یک موضوع واحد در دهها سایت مختلف پراکنده باشد، یافتن کامل آن غیرممکن است. برای مثال، اطلاعات یک مشتری خاص ممکن است قراردادش در سایت حقوقی، صورتحسابهایش در سایت مالی، و گزارشهای پروژهاش در سایت فنی باشد. یک تصمیم سازمانی هوشمند، طراحی “هابها” یا سایتهای مرکزی برای موضوعات کلیدی است که یا محتوا را در خود گردآوری میکنند یا دست کم پیوندهای یکپارچه به تمام محتوای پراکنده در سراسر سازمان ارائه میدهند.
همچنین بخوانید: فارسی ساز شیرپوینت
شیرپوینت یک محصول زنده است که به طور منظم بهروزرسانیهای امنیتی، رفع اشکال و ارتقاهای عمده دریافت میکند. برخی سازمانها پس از راهاندازی اولیه، بودجه و نیروی انسانی لازم برای همراهی با این بهروزرسانیها را تأمین نمیکنند. آنها سالها روی یک نسخه قدیمی میمانند که ممکن است با سایر نرمافزارها ناسازگار شده، دارای حفرههای امنیتی باشد و از قابلیتهای جدید بیبهره باشد. این تصمیم کوتاهبینانه، در بلندمدت هزینه بیشتری برای مهاجرت اجباری و حل مشکلات انباشته تحمیل میکند.
این یک اشتباه فاجعهبار است که میتواند کل دارایی اطلاعاتی سازمان را به خطر بیندازد. ممکن است سازمان فرض کند که ارائهدهنده خدمات ابری مسئول همه چیز است، یا پشتیبانگیری را تنظیم کرده اما هرگز فرآیند بازیابی اطلاعات را آزمایش نکرده است. وقتی حادثهای رخ دهد (مثلاً حذف تصادفی یک سایت مهم توسط یک کاربر)، سازمان متوجه میشود که یا پشتیبانی وجود ندارد، یا بازیابی بسیار زمانبر است. تصمیم برای داشتن یک استراتژی روشن پشتیبانگیری و بازیابی، بخشی ضروری از مدیریت هر سیستم حیاتی است.
شیرپوینت بدون نظارت، مانند ماشینی است که هیچ چراغ هشداری ندارد. سازمان باید بر شاخصهایی مانند فضای ذخیرهسازی مصرفی، فعالیت کاربران، سرعت لود صفحات و خطاهای سیستم نظارت کند. اگر چنین نظارتی وجود نداشته باشد، مشکلات به تدریج و در خفا رشد میکنند تا زمانی که به یک بحران تبدیل شوند. مثلاً فضای ذخیرهسازی پر میشود و کل سیستم از کار میافتد، یا یک سایت بسیار کند باعث نارضایتی عمومی میشود. نظارت مستمر به شناسایی به موقع مشکلات و برنامهریزی برای توسعه منابع کمک میکند.
اگر کاربران ندانند وقتی به مشکلی برخوردند باید به کجا مراجعه کنند، یا اگر پس از گزارش، پاسخی دریافت نکنند، اعتماد خود را به سیستم از دست میدهند. یک تصمیم سازمانی ضعیف، نداشتن یک سیستم بلیطدهی (تیکتینگ) ساده یا یک نقطه تماس واحد برای پشتیبانی شیرپوینت است. کاربران مجبور میشوند به صورت شفاهی و پراکنده از همکاران کمک بخواهند، که این موضوع باعث تلف شدن وقت جمعی و تکرار خطاها میشود. یک کانال پشتیبانی منظم، بازخوردهای ارزشمندی نیز برای بهبود سیستم فراهم میآورد.
نیازهای سازمان ثابت نیستند. ممکن است پس از چند سال، تمرکز سازمان از مدیریت اسناد به سمت ارتباطات داخلی یا مدیریت پروژههای چابک تغییر کند. اگر شیرپوینت هرگز مورد بازنگری استراتژیک قرار نگیرد، از نیازهای جدید سازمان عقب میماند. سازمان باید هر سال یا دو سال یکبار، با تشکیل یک کارگروه، بررسی کند که آیا شیرپوینت همچنان اهداف تجاری را برآورده میکند؟ آیا از قابلیتهای جدیدی که میتوانند مفید باشند استفاده نمیشود؟ این بازنگری، سیستم را زنده و مرتبط نگه میدارد.
گاهی اوقات تصمیم برای استفاده از نسخه ابری یا داخلی شیرپوینت، بر اساس دانش قدیمی مدیران، شنیدهها یا ترس از cloud گرفته میشود، نه بر اساس یک تحلیل واقعی از نیازها، بودجه، توان فنی و ملاحظات امنیتی سازمان. یک سازمان کوچک با منابع فنی محدود که نسخه داخلی را انتخاب میکند، به زودی درگیر هزینههای سنگین خرید سرور، نصب، نگهداری و امنسازی میشود. برعکس، یک سازمان بزرگ با نیازهای سفارشیسازی پیچیده ممکن است با انتخاب نسخه ابری خالص، با محدودیتهایی مواجه شود.
این تصمیم حیاتی است. برخی صنایع (مثل بهداشت و درمان، مالی یا دفاعی) مقررات سختگیرانهای در مورد محل ذخیرهسازی دادهها دارند. انتخاب نسخه ابری عمومی بدون اطمینان از رعایت این مقررات توسط ارائهدهنده، میتواند سازمان را با جریمههای سنگین یا شکایت مواجه کند. از طرف دیگر، انتخاب نسخه داخلی بدون سرمایهگذاری کافی روی امنیت (مثل فایروال، آنتیویروس، رمزنگاری) میتواند دادهها را در معرض خطر بیشتری قرار دهد. این تصمیم باید با مشورت متخصصان امنیت و حقوقی گرفته شود.
مدل ابری معمولاً به صورت پرداخت ماهانه یا سالانه است و هزینههای پنهان کمتری دارد (مانند برق، خنککنندگی، تعویض سختافزار). مدل داخلی هزینه اولیه خرید سختافزار و نرمافزار بالایی دارد، اما پس از آن هزینههای عملیاتی ثابت دارد. سازمانها اغلب تنها هزینه اولیه را میبینند و هزینههای بلندمدت نیروی انسانی متخصص، ارتقا سختافزار، مصرف انرژی و از دست رفتن داده را در محاسبات خود لحاظ نمیکنند. یک مقایسه دقیق مالی چندساله برای تصمیمگیری ضروری است.
شیرپوینت در یک جزیره کار نمیکند. ممکن است سازمان نیاز داشته باشد با سیستم ذخیرهسازی شبکه داخلی، نرمافزارهای دسکتاپ قدیمی یا پایگاههای داده خاص خود ارتباط برقرار کند. انتخاب مدل استقرار میتواند این یکپارچهسازی را آسان یا غیرممکن کند. مثلاً نسخه ابری ممکن است در ارتباط مستقیم با یک سرور داخلی قدیمی مشکل داشته باشد. اگر این نیازهای یکپارچهسازی از ابتدا در نظر گرفته نشود، پس از اجرا با بنبست فنی مواجه خواهیم شد.
برای رفع کمبودهای هر دو مدل، برخی سازمانها به سمت مدل ترکیبی میروند. اما این تصمیم اگر بدون طراحی دقیق گرفته شود، میتواند پیچیدهترین و گرانترین گزینه باشد. ممکن است برخی دادهها روی cloud و برخی داخلی باشند، که مدیریت دسترسی، همگامسازی و امنیت را بسیار دشوار میکند. سازمان باید دقیقاً مشخص کند که کدام دادهها و کاربردها کجا قرار میگیرند و چگونه با هم تعامل خواهند داشت. در غیر این صورت، به جای بهرهگیری از بهترین هر دو دنیا، بدترین جنبههای آنها را تجربه خواهد کرد.
شیرپوینت برای شکستن دیوارهای بین بخشها و تسهیل جریان اطلاعات طراحی شده است. اما اگر فرهنگ سازمانی بر پایه مالکیت انحصاری اطلاعات و رقابت داخلی باشد، این پلتفرم محکوم به شکست است. مدیران بخشها ممکن است تمایلی به اشتراکگذاری دانش، اسناد و بهترین روشهای کاری خود با دیگر بخشها نداشته باشند. آنها سایتهای خود را به دژهای محصور تبدیل میکنند. در چنین فرهنگی، شیرپوینت تنها ابزاری برای تقویت همان سیلوها میشود، نه تضعیف آنها. تغییر این فرهنگ، پیشنیاز موفقیت هر ابزار همکاری است.
اگر سازمان از افرادی که محتوای باکیفیت تولید میکنند، دیگران را آموزش میدهند یا قالبهای مفید میسازند، قدردانی نکند، انگیزه مشارکت از بین میرود. مردم به رفتارهایی که پاداش داده میشود تمایل نشان میدهند. اگر تنها معیارهای عملکرد فردی، کارهای سنتی باشد، کسی وقت خود را صرف غنیکردن یک سیستم جمعی مانند شیرپوینت نخواهد کرد. سازمان باید در سیستم ارزیابی عملکرد، شاخصهایی برای “همکاری” و “اشتراک دانش” بگنجاند و به طور علنی از الگوهای موفق تقدیر کند.
اگر مدیریت از قابلیتهای گزارشگیری و ثبت فعالیت شیرپوینت برای زیر نظر گرفتن ساعتی کارکنان و ایجاد ترس استفاده کند، به طور قطع روح همکاری را در آن میکشد. کاربران احساس میکنند که هر حرکت آنها زیر ذرهبین است، بنابراین یا استفاده از سیستم را به حداقل میرسانند، یا فقط فعالیتهای بیخطر و پیشپاافتاده را در آن انجام میدهند. شیرپوینت باید به عنوان فضایی امن برای آزمایش، یادگیری و همکاری دیده شود، نه یک دستگاه نظارتی. اعتماد، سنگ بنای پذیرش هر سیستم اجتماعی است.
مدیران میانی که قدرت خود را از کنترل اطلاعات میدانند، ممکن است بزرگترین مخالفان یک سیستم شفاف مانند شیرپوینت باشند. آنها نگران هستند که با در دسترس قرار گرفتن اطلاعات برای دیگران، نقش واسطهگری آنها کمرنگ شود. این لایه مدیریتی اگر متقاعد نشود، میتواند به طور فعال یا منفِعل، کارکنان خود را از استفاده مؤثر از سیستم منصرف کند. موفقیت شیرپوینت نیازمند حمایت قاطع مدیریت ارشد و همراه کردن مدیریت میانی با نشان دادن مزایای این شفافیت برای اثربخشی کلی تیم است.
در نهایت، مردم برای “چرا”ها انگیزه پیدا میکنند، نه برای “چگونه”ها. اگر سازمان نتواند یک داستان روشن و جذاب درباره اینکه شیرپوینت چگونه کار همه را آسانتر میکند، کیفیت خدمات را افزایش میدهد و به اهداف بزرگتر سازمان کمک مینماید، تعریف کند، سیستم تنها یک دستورالعمل اداری دیگر خواهد بود. ارتباط دادن استفاده از شیرپوینت به مأموریت، چشمانداز و ارزشهای سازمان، به آن معنا و هدف میبخشد. بدون این روایت مشترک، حتی فنیترین و زیباترین پیادهسازی نیز در درازمدت با بیتفاوتی مواجه خواهد شد.
پاسخ: نبود یک استراتژی و چشمانداز واضح از سوی مدیریت، پیش از آغاز پیادهسازی. بسیاری از سازمانها بدون تعریف دقیق اهداف و مشکلاتی که قصد حل آن را دارند، مستقیم به سراغ نصب و تنظیم فنی میروند.
پاسخ: لزوماً نه، اما قطعاً نیاز به تعیین «مالک» یا «تیم مسئول» داخلی دارید. این افراد میتوانند از کارمندان موجود باشند که آموزش دیدهاند و مسئولیت نظارت، آموزش دیگران و توسعه ساده پلتفرم را بر عهده میگیرند.
پاسخ: با درگیر کردن آنها از مراحل اولیه طراحی، نشان دادن مزایای مستقیم شیرپوینت بر سادهسازی کارهای روزمرهشان، و ارائه آموزشهای مستمر، کاربرمحور و مبتنی بر نیازهای واقعی آنها.
پاسخ: خیر، این یک اشتباه رایج است. بهتر است پیادهسازی به صورت تدریجی و گامبهگام باشد. ابتدا چند عملکرد اصلی و مورد نیاز همه را راهاندازی کنید و پس از عادت کردن کاربران، امکانات پیچیدهتر را اضافه نمایید.
پاسخ: بله، اما نیاز به برنامهریزی دارد. باید پروژهای تعریف کنید تا ابتدا ساختار ایدهآل و جدید را بر روی کاغذ طراحی کنید، سپس به تدریج و با انتقال کنترل شده محتوا، سایتها را به ساختار جدید منتقل نمایید. ممکن است نیاز به مشاوره تخصصی باشد.
شیرپوینت، به خودی خود، یک پلتفرم انعطافپذیر و قوی برای مدیریت اسناد، خودکارسازی گردش کار و تقویت همکاری تیمی است. اما همانند هر ابزار فناوری دیگری، موفقیت آن در گرو نحوه به کارگیری و مدیریت آن است. متأسفانه، بسیاری از سازمانها، بدون درک کامل نیازهای خود و با اتخاذ تصمیمهای عجلهای و فاقد برنامهریزی بلندمدت، راه را برای شکست این پروژه هموار میکنند. نداشتن استراتژی واضح، نادیده گرفتن آموزش کاربران، پیادهسازی ساختارهای پیچیده و نامنظم، و عدم تعیین مالک و مسئول برای پلتفرم، از جمله اشتباهات رایجی هستند که شیرپوینت را به سیستمی بیثمر تبدیل میکنند. در چنین شرایطی، این پلتفرم نه تنها به بهبود فرآیندها کمک نمیکند، بلکه به منبعی از سردرگمی، نارضایتی کاربران و اتلاف منابع تبدیل میشود.
کلید موفقیت، در نگاه به شیرپوینت به عنوان یک پروژه مدیریت تغییر است، نه یک پروژه صرفاً فنی. این امر نیازمند تعهد مدیریت ارشد، مشارکت کاربران نهایی از ابتدای کار، طراحی ساختاری ساده و مقیاسپذیر، و سرمایهگذاری مستمر بر آموزش و پشتیبانی است. زمانی که سازمانها از تصمیمهای شتابزده و بدون پشتوانه فکری پرهیز کنند و برای پیادهسازی و نگهداری این سیستم برنامهای مدون داشته باشند، شیرپوینت میتواند به همان ابزار تحولآفرینی تبدیل شود که برای آن ساخته شده است.
برای درک بهتر اصول اولیه و بهترین روشهای استفاده از این پلتفرم، پیشنهاد میکنیم مطلب «آغاز کار با شیرپوینت» را در وبسایت رسمی مایکروسافت مطالعه فرمایید. برای مطالعه این راهنمای کاربردی، اینجا کلیک کنید.
در خبرنامه ما مشترک شوید و آخرین اخبار و به روزرسانی های را در صندوق ورودی خود مستقیماً دریافت کنید.

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