سفر پیاده‌سازی نرم‌افزار هزار مایلی با فاز صفر آغاز می‌شود (جیمز موناگان)

تبریک می گویم. شما تصمیم گرفته اید نرم افزاری را پیاده سازی کنید و می خواهید موفق باشد. آیا چابک یا آبشار یا Lean یا Scrum یا چیز دیگری کاملاً خواهد بود. در حالی که اجرای موفق پروژه الزامات خاص خود را برای اجرای آن دارد
موارد زیادی هستند که باید قبل از شروع بازی در نظر گرفت.

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

عجله در اجرای فن آوری جدید دارای مشکلات متعددی است، اما هیچ یک از آنها رایج تر از شروع به کارگیری/یکپارچه سازی یک سیستم بدون در نظر گرفتن اینکه تصویر بزرگتر کلی پس از تکمیل آن چگونه به نظر می رسد، نیست. پروژه های بسیار زیادی زخمی شده اند
در ابتدا، زیرا برخی از بخش های کلیدی فناوری در طرح کلی لحاظ نشده بود. با تمام فین تک ها و اخلالگران موجود در بازار امروز، همه تلاش خواهند کرد تا به طور یکپارچه با یکدیگر ادغام شوند، اما بدون درک کامل
of چگونه شما می خواهید آنها به هم متصل شوند و به چه دلیل، می توانید به راحتی متوجه شوید که مدل عملیاتی هدف خود را در میانه راه دوباره انجام می دهید و مجبور هستید تمام تلاش ها و منابعی را که تاکنون صرف کرده اید دور بریزید. این مانند تلاش برای ساخت هواپیما در حالی است
پرواز با آن یا تعویض لاستیک ماشین در حین رانندگی. TOM های معمولی دارای یک سیستم مدیریت ارتباط با مشتری (CRM) برای استفاده از مشتری رو به رو خواهند بود که به سیستم مدیریت چرخه عمر مشتری متصل می شود که دارای یک موتور گردش کار و قوانین است.
انجام وظایف لازم به افراد مربوطه برای تکمیل ورود داده ها / بارگذاری اسناد / اعتبارسنجی و تأیید. ممکن است یک سیستم مدیریت داده اصلی (MDM) وجود داشته باشد که به عنوان منبع رکورد/کپی طلایی در نظر گرفته شود، اما اغلب اوقات این یک سلسله است.
سیستمی از چندین فروشگاه داده انباشته یا یکپارچه با سیستم های مختلف که می توانند رکوردها را به روز کنند. می‌تواند سیستم‌های تراکنش/معامله/وام دهی با خدمات نظارت بر تراکنش داخلی یا یکپارچه وجود داشته باشد. می تواند ارائه دهندگان شخص ثالثی برای داده ها/اسناد وجود داشته باشد
یا اخبار / اخبار منفی / اهداف غربالگری. همه یا برخی از اینها می توانند مبتنی بر ابر یا بر روی سیستم های مقدماتی نیز باشند. بنابراین، اکنون دوباره از شما می‌پرسم، آیا فکر کرده‌اید که این 1 تکه فناوری جدید در کجای TOM کلی شما قرار می‌گیرد و آیا نسخه نهایی است یا شما هستید؟
آن را در تنظیمات فعلی ادغام کنید، اما قصد دارید در آینده آن را تغییر دهید

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

یک اشتباه رایج وجود دارد که به عنوان اشتباه هزینه غرق شده شناخته می شود که به موجب آن فقط به این دلیل که شما X دلار/یورو/پوند را روی یک سیستم خرج کرده اید، اعتراف به شکست و حذف آن بسیار دور از ذهن است. یا اینکه شکسته نیست و نیازی به تعمیر ندارد. یا اینکه خیلی جا افتاده است
در سیستم های فعلی بتوان آن را حذف یا جایگزین کرد. اگر اینطور است، احتمالاً بدون اینکه متوجه شوید با یک نقطه شکست مواجه شده اید. راه حل های فناوری مدرن انعطاف پذیر هستند و باید برای تغییر ساخته شوند. ادغام/اکتساب های قبلی
یا ادغام سیستم ها باعث شده است که فناوری یکپارچه شود و روند معمول این است که به سادگی آن را به کار بیندازیم. اینها باید به عنوان فرصتی در نظر گرفته شوند تا در مورد نحوه انجام کاری تجدید نظر کنند و برای راه کارآمدتر تلاش کنند. دومین
برای این، بیشتر فناوری‌های جدید دارای پیشنهادات/ماژول‌ها/ویژگی‌های مشابهی مانند گزارش‌گیری، داشبورد، گردش کار، موتورهای قوانین مدیریت پرونده، استودیوی پیکربندی هستند یا ادعا می‌کنند که دارند. هدف از این کار جذب گسترده ترین مخاطبان ممکن است
برخی از مردم فکر می کنند "چرا باید X بخرم در حالی که Y قبلاً این توانایی را دارد؟". اما با در نظر گرفتن این موضوع، آیا واقعاً می خواهید CRM خود را به یک سیستم نظارت بر تراکنش تبدیل کنید؟ یا سیستم حساب شما وارد دروازه MDM شما می شود؟ یا MDM شما به عنوان اصلی
نقطه ورود داده ها می دانید که در نهایت هزاران رکورد با شماره تلفن 12345678 خواهید داشت.

کارکنان/نقش ها

برای موفقیت هر پیاده سازی، شما نقش های تعریف شده خود را در هر دو طرف پروژه خواهید داشت. مال شما و فروشندگان بدیهی است که بستگی به بودجه، محدوده و جدول زمانی دارد. ممکن است یک پیاده سازی 4 هفته ای مبتنی بر ابر داشته باشید که به 2 کارمند نیاز دارد
فروشنده یا می تواند 10 مرحله از نسخه های اصلی 12 هفته ای با رویکرد الزامات چابک دو هفته ای متشکل از تحلیلگران کسب و کار/محصول، توسعه دهندگان، کارشناسان موضوع، آزمایش کنندگان تضمین کیفیت، که همگی به نقش های خردسال و ارشد، پروژه نیاز دارند باشد.
مدیران برای هر خط کسب و کار / منطقه / حوزه قضایی و یک مدیر برنامه برای نظارت بر همه آن. یک حامی پروژه را انتخاب کنید و به راحتی می توانید متوجه شوید که چرا نرم افزار سازمانی گران می شود، گاهی اوقات گران می شود. این نیز قبل از در نظر گرفتن سطوح کارکنان است
که باید برای مطابقت تخصیص دهید. فراموش نکنید که کارکنان شما که در این پروژه مشارکت دارند مدت زمان قابل توجهی از وظایف روزمره خود دور خواهند بود. مهم است که مطمئن شوید کارکنان فروشنده با تجربه هستند و تجربه نکرده اند
اخیراً برای پاسخگویی به تقاضای پروژه شما استخدام شده است.

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

مهاجرت داده

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

یکپارچگی

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

دسترسی به سیستم - سیاست های Infosec

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

خریداران در مقابل کاربران

آیا کاربران نهایی فناوری جدید در فرآیند تصمیم گیری دخیل هستند؟ اگر در نهایت تصمیم بگیرند که آنچه در حال ساخت است برای اهداف آنها مناسب نیست تصمیم گیری از طرف دیگر کاربران چه فایده ای دارد. نبرد بین تجارت و
فناوری اطلاعات یک امر ثابت است که در همه جا رخ می دهد و از نظر اینکه چه کسی باید تصمیم بگیرد به عقب و جلو می چرخد. طراحی سیستم، اغلب، انتظار می رود که هر مشکلی را برای هر کاربر به طور کامل حل کند. بیش از مهندسی فناوری برای حل 100٪
تحسین برانگیز است اما در نهایت یک تلاش سنگین منابع است. هدف اولیه باید حل کردن اکثریت باشد و قبل از اقدام به موارد لبه تا تحویل موفقیت آمیز صبر کنید. آن 20% یا 10% نهایی مسائل نباید هدف اصلی کسب را متوقف کند
این فناوری است، اما اغلب اوقات همه چیز مصرف می شود. سوالی که باید از خود بپرسید این است که روز اول به طور قطعی چه چیزی لازم است، و گزینه های خود را به یک زیر مجموعه محدود کنید زیرا پاسخ پیش فرض بدون همیشه، همیشه، همه چیز است.

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