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

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

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

قدم اول: شناخت مشکلات و نیازهای فعلی در شرکت

• مشکلات کاربران برای مدیریت فعالیتهایی که به آنها سپرده میشود (به طور مثال وظایف دو ماه آینده را چگونه میتوان مدیریت کرد)
• مشکلات کاربران در حین مدیریت اطلاعاتی که به آنها داده شده است جهت انجام امور شرکت (به طور مثال اطلاعات مرتبط با حسابداری که در اختیار کارمندان بخش حسابداری قرار میگیرد)
• مشکلات کاربران در ارتباط با دیگر همکاران (به طور مثال وقتی یک درخواست خرید ثبت میشود تا به خرید واقعی منجر شود، فرایند طولانی را طی خواهد کرد، که خیلی از واحدهای یک سازمان را درگیر خواهد کرد، در همین فرایند ساده، درخواست کننده، واحد حسابداری، واحد تدارکات و واحد انبار درگیر خواهند بود. حال مشکلی در این ارتباط بین واحدها باشد باید در این مرحله شناسایی گردد)
• مشکلات نرم افزاری (باگهای موجود، عدم پوشش نیازهای کاربران، عدم کارکرد صحیح نرم افزار در پردازش یا حتی بایگانی اطلاعات)
• شناسایی گزارشات مورد نیاز

اگر دقت کرده باشید، در ابتدا سراغ مشکلات رفتیم، چرا که وقتی مشکلات را شناسایی کنیم، میتوانیم با ارائه ی یک نرم افزار جامع، مشکلات کاربران را مرتفع نماییم. بدیهی است که وظیفه اصلی هر نرم افزار، در ابتدا رفع مشکلات کاربران و ایجاد سهولت در انجام امور میباشد.

سند شرح نیازها و امکانات مورد نیاز نرم افزاری یک سازمان را به اصلاح RFP میگویند. RFP مخفف Request For Proposal است. البته که نوشتن RFP قواعد و قوانین خودش را دارد و میتواند یک فاز بسیار طولانی از یک پروژه نرم افزاری باشد. اما ما قصد نداریم در این مقالبه به این موضوع بپردازیم. سعی داریم تا در این مقاله بیشتر به الزام داشتن شرح نیاز به صورت مکتوب در یک سازمان برای خرید نرم افزار بپردازیم.

معمولا مشکلی که در سازمانها به وجود می آید به اینگونه است:

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

پس بهتر است برای عدم گمراهی مسیر شناخت نرم افزارها حتما و حتما، نیازها به صورت مکتوب در سندی ذکر شود که این سند را میتوان با کمی اغماض همان RFP نامید.

قدم دوم: طراحی ERD

از این قدم به بعد زمانی مورد نیاز است که ما قصد داریم تا با یک پلتفرمی شبیه به Sharepoint یا شیرپوینت، نیاز نرم افزاری سازمان خود را مرتفع نماییم.

ERD چیست

ERD یا همان Entity Relational Diagram، همان نقشه ارتباط بیند فیلدهای اطلاعاتی است. بیایید یک مثال ساده جهت درک این دیاگرام یا نقشه بزنیم، فرض کنیم میخواهیم اطلاعات پرسنل خود را با شیرپیونت نگهداری کنیم. بیایید با هم بررسی کنیم که دقیقا چه فیلدهایی به منظور مدیریت این اطلاعات مورد نیاز است:

نام جدول 1: اطلاعات پایه ی اشخاص

نام فیلدها: شناسه ی یکتا(primary key) ، نام، نام خانوادگی، نام پدر، شماره شناسنامه، محل تولد، تاریخ تولد

نام جدول 2: اطلاعات دیگر افراد خانواده پرسنل

نام فیلدها: شناسه ی یکتا(primary key) ، نام ، نام خانوادگی، نسبت با پرسنل مربوطه

همان طور که میبینید مد نظر است تا این دو جدول را با هم مرتبط نماییم. یعنی اینکه بدانیم هر فردی که اطلاعاتش در جدول 2 قرار دارد، به کدام یک از پرسنل ما مرتبط است. پس باید یک فیلد دیگری به عنوان پرسنل مربوطه به جدول 2 اضافه کنیم.

erd چیست

پرسنل مربوطه از جدول2 مرتبط است با شناسه ی یکتا از جدول 1

این یک نمونه ساده از نقشه ارتباط بین فیلدها بود، طبیعتا در یک سازمان، به این سادگی ها نمی توانیم این ارتباطها را کشف نماییم. چرا که مثال ما در یک زمینه خاص اتفاق افتاد، ما به اصلاح به اطلاعات حول یک محور سامانه میگوییم. اگر بخواهیم ERD یک سامانه را طراحی کنیم به نسبت کار ساده تری در پیش داریم. به طور مثال، سامانه منابع انسانی، سامانه فناوری اطلاعات، سامانه حسابداری، سامانه مدیریت و …

در اینگونه موارد ERD ها بسیار بزرگتر از مثال ما هستند و ارتباطات آنها هم پیچیده تر میباشد. اما نگران نباشید، چرا که پیچیده ترین ERD ها هم ابتدا از یک جدول شروع شدند و مرحله به مرحله رشد پیدا کردند.

داشتن یک ERD مدون و مکتوب، کمک بسیار زیادی به شما در رشد سامانه ها و تغییرات بعدی آنها خواهد کرد. این قدم از کار را بسیار جدی بگیرید.

این یک نمونه از یک ERD واقعی و نسبتا بزرگ

انواع ERD چیست

کشیدن این نقشه معمولا با سلایق و درخور فعالیت افراد متفاوت میباشد، مدلهایی که در مثالهای بالا به آن اشاره کردیم را معمولا با نام Data model میشناسیم نه ERD، اما برای فهم ساده تر هر یک از جداول بسیار کارگشاست. اما اگر به دنبال کشیدن ERD هستید، ابتدا باید شروع به شناخت Entity ها کنیم. Entity در شیرپوینت را میتوان به تعبیری همان Content type معنا کرد. در مثال بالا ما دو entity داریم، entity اول همان پرسنل هستند و entity دوم افراد متفرقه میباشند.

هر یک از این entity ها یکسری صفات دارند که به اصطلاح آنها را Attribute مینامیم، Attribute ها همیشه به entity ها وصل هستند و در نهایت entity ها به یکدیگر مرتبط میشوند. به صورت شکل زیر

erd چیست

پس در قدم دوم باید تمامی این ERD ها یا همان Data model ها را بیابیم و به صورت مکتوب آنها را تدوین نماییم.

قدم سوم: طراحی فرم

شاید یکی از مهمترین مواردی که کاربران با آن سر و کار دارند همان فرمها هستند، پس باید بر روی طراحی هر یک از این فرمها زمان و انرژی زیادی گذاشت، البته که با نرم افزارهای طراحی فرم مانند اینفوپث، خیلی زمان زیادی جهت طراحی فرم صرف نمیشود، اما اگر بنا باشد تا هر یک از فرمها را به صورت کد نویسی پیاده سازی کنیم، آنگاه زمان بسیار زیادی صرف تغییرات میشود، لذا بهتر است که ابتدا فرم را به صورت یک عکس طراحی کنیم (فرمی که به فیلدهای نرم افزاری وصل نیست و با نرم افزارهایی مانند infopath یا visio یا حتی Photoshop طراحی میشود به اصطلاح prototype میگویند) و پس از تائید توسط کاربران و مدیران، سپس آن را به صورت نرم افزاری تبدیل نماییم.

قدم چهارم: طراحی گزارشات

همیشه پس از اتمام پیاده سازی هر فرایند یا سامانه، مشکلی که به چشم میخورد این است که گزارشات مورد نیاز مدیران یا بخشی از کاربران در سامانه دیده نشده است، چرا؟ به این دلیل که در ابتدای طراحی سامانه این گزارشات بررسی نشده اند. به عنوان مثال، ما نیاز داریم گزارش تعداد پرسنل هر واحد سازمانی را داشته باشیم، این در صورتی است که ما در جدول1 اصلا نام واحد را نگهداری نمیکنیم و نمیتوانیم این گزارش را از سامانه خروجی بگیریم. لذا بسیار مهم است که از همان ابتدا بدانیم چه گزارشاتی را بناست از سامانه به عنوان خروجی استفاده کنیم.

قدم پنجم: تحویل و آموزش سامانه

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

بهترین روش برای آنکه کمترین انرژی از کاربران و ارائه دهندگان سامانه (شیرپوینت کاران) جهت حل مشکلات نرم افزاری، صرف شود، آن است که یک شخص را از بین گروه کاربران یک سامانه مسئول آموزش دادن و پاسخگویی به مشکلات کنیم و این شخص مذکور را در روند طراحی و حل مشکلات ذخیل نماییم. چرا که همیشه بین اشخاص فنی و کاربران یک اختلاف دیدگاه وجود دارد که منشا آن اختلاف نگرش فنی و غیر فنی آنهاست. اینجاست که شخص مذکور به دلیل دخیل بودن در فرایند تکمیل نرم افزار دانش لازم جهت درک دیدگاه افراد فنی را پیدا میکند و بدلیل هم شکل بودن وظایفش با کاربران، به طور کامل کاربران را هم درک خواهد کرد. ما اسم این شخص را سوپروایزر مینامیم. این نقش جزو نقشهای حیاتی جهت پیاده سازی صحیح یک سامانه است.

قدم ششم: ایجاد مستندات سامانه

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