مبارک ہو آپ کے پاس ایک مسئلہ، ایک پروجیکٹ، ایک بجٹ اور ایک آخری تاریخ ہے۔ اس پر لاشیں پھینکنے کے بجائے، سافٹ ویئر ہی حل ہے لیکن اب آپ کو فیصلہ کرنا ہوگا کہ تعمیر کریں یا خریدیں، یہی سوال ہے۔ یا یہ ہے؟ مجھے اتنا یقین نہیں ہے کہ اب یہ ایک واضح فیصلہ ہے۔
گھر کے پروگرامرز کی خدمات حاصل کرنے کا حوالہ دینے کے لیے استعمال کریں تاکہ جو بھی سسٹم ضروری ہو اس کو کوڈ کرنے کے لیے استعمال کریں اور ان شیلف پروڈکٹس کو خریدیں جو خریدی اور چلائی جا سکتی ہیں۔ یہ تب سمجھ میں آیا جب ہم اکاؤنٹنگ سسٹم، ٹریڈنگ سسٹم، CRM، رپورٹنگ، کے بارے میں بات کر رہے تھے۔
قرض دینا، جمع کرنا، CLM، وغیرہ۔ اب ہم کم کوڈ والے ماحول میں رہتے ہیں جہاں کچھ بنانے کے لیے کوڈنگ کے تجربے کی ضرورت نہیں ہوتی ہے۔ اسے ڈریگ اینڈ ڈراپ کیا جا سکتا ہے۔ جوڑے کہ شیلف کے حل کو خریدنے کے ساتھ جو اس حد تک اپنی مرضی کے مطابق بنائے جاتے ہیں کہ آپ کے طور پر ہو سکتا ہے
اچھی طرح سے بنایا ہے. تو یہ ہمیں تعمیر کرنے یا خریدنے کا فیصلہ کرنے کے لیے کہاں چھوڑ دیتا ہے؟ آئیے دیکھتے ہیں کہ ہمیں اصل میں کیا ضرورت ہے۔
کوئی بھی جدید نظام اب داخلے کے ایک پوائنٹ پر بھروسہ نہیں کر سکتا۔ کلائنٹ کی توقعات یہ بتاتی ہیں کہ مختلف چینلز ضروری ہیں۔ ذاتی طور پر، فون پر براہ راست یا کال سینٹر، ای میل، سوشل میڈیا، ایس ایم ایس، ویب، موبائل، ٹیبلیٹ – موبائل فعال اور مقامی دونوں
ایپس، سبھی مواد یا سیاق و سباق کو کھونے کے بغیر قابل تبادلہ ہونے کی ضرورت کے ساتھ۔ ایک گاہک جو برانچ/اسٹور میں یا ذاتی طور پر شروع ہوتا ہے لیکن اسے اپائنٹمنٹ کے لیے جانا پڑتا ہے وہ اس دن کے بعد آن لائن لاگ ان ہونے پر وہیں سے شروع کرنا چاہتا ہے جہاں سے انہوں نے چھوڑا تھا۔ یا
اگر وہ آن لائن شروع کرتے ہیں لیکن مایوس ہو جاتے ہیں اور مدد کے لیے کال کرتے ہیں، تو وہ نہیں چاہتے کہ اس عمل کو شروع سے شروع کرنا پڑے۔ یہ اندرونی اسٹیک ہولڈرز پر بھی لاگو ہوتا ہے۔ کسی تنظیم کے اندر معلومات کا سلسلہ اتنا ہی لچکدار ہونا چاہیے جتنا کہ کلائنٹ کا سامنا ہے۔
اختیارات.
تو ہمارے آغاز کے لئے آگے کیا کہیں بھی ڈیٹا ان پٹ؟ ٹھیک ہے، ایک وجہ ہے کہ ہمیں پہلے اس ڈیٹا کی ضرورت ہے۔ چاہے ایک نیا کلائنٹ تنظیم کے ساتھ کام کرنا چاہتا ہے، ایک موجودہ کلائنٹ ایک نئی مصنوعات یا خدمت چاہتا ہے، یا یہاں تک کہ روزمرہ کے سوالات، شکایات
یا معلومات کی درخواستیں۔ درخواست کو مؤثر طریقے سے اور آسانی سے مکمل کرنے کے لیے ان سب کو متعین لیکن لچکدار عمل شروع کرنا چاہیے۔ اس عمل کی عام طور پر تعریف کی جاتی ہے اور عام طور پر عملے کو تربیت دی جاتی ہے کہ وہ پہلے سے طے شدہ کاموں کی ترتیب پر عمل کریں۔
کچھ ڈیٹا ان پٹ پر مبنی کارروائیاں۔
نہ ہی اختتامی صارفین اور نہ ہی سسٹم کے صارفین کو کہیں بھی اہم معلومات کو دوبارہ دوبارہ کرنا چاہئے اگر یہ پہلے ہی کہیں پکڑی گئی ہو۔ درحقیقت، اگر معلومات تنظیم کے اندر کہیں بھی یا فریق ثالث کے ذرائع جیسے ڈیٹا فراہم کرنے والے، کریڈٹ بیورو، سے دستیاب ہو،
اسکریننگ فراہم کرنے والے، وغیرہ۔ یہ تمام عمل کے دوران ان تمام صارفین کے لیے قابل رسائی ہونا چاہیے جنہیں اس کی ضرورت ہے۔ عمل کی وضاحت کی گئی ہے لیکن ٹچ پوائنٹس کو ہر جگہ قابل تبادلہ ہونا چاہیے اور جہاں ممکن ہو وہاں جمع کیے گئے ڈیٹا کو مربوط کیا جانا چاہیے اور جہاں قابل اجازت ہو وہاں ڈھانچہ بنایا جانا چاہیے۔
ڈراپ ڈاؤن مینو، تلاش کی قدریں، تاریخ کی فیلڈز اور کنٹرول شدہ مفت ٹیکسٹ ویلیوز کو یقینی بنانے کے لیے کہ زیادہ سے زیادہ ڈیٹا کوالٹی کیپفرنٹ کریں۔ یہ پورے عمل میں بہت زیادہ آٹومیشن اور کم استثنیٰ ہینڈلنگ کی اجازت دیتا ہے۔
اب جب کہ ڈیٹا فعال طور پر پکڑے جانے یا اپ ڈیٹ کرنے کے عمل میں ہے، مصنوعی ذہانت کا اطلاق کیا جا سکتا ہے۔ عملے کو تمام تفصیلات جاننے کی ضرورت نہیں ہے اور یہاں تک کہ نئے ممبران زیادہ پیچیدہ معاملات پر کام کر سکتے ہیں کیونکہ سسٹم پالیسی کوڈڈ رولز استعمال کر رہا ہے۔
خود کار طریقے سے فیصلے کرنے کی منطق جن کو سنبھالنے کے لیے عملے کو پہلے وسیع تربیت اور تجربہ ہونا پڑتا تھا۔ نگرانی اور حتیٰ کہ کوالٹی کنٹرول چیک یا ضرورت پڑنے پر دستی مداخلت کے لیے قطعی استثنائی قطاروں کی اجازت دیتے ہوئے مزید غلطیوں کی ضرورت نہیں۔
یہ سب ایک منظم نقطہ نظر کی ضرورت ہے. منیلا فولڈر کا پرانا خیال جو عملے کے ارکان کے دراز میں اپنے کلائنٹ کے پورٹ فولیو کے لیے بیٹھتا ہے پرانا ہے اور ایک غیر ضروری خطرہ پیدا کرتا ہے۔ تنہائی میں پروسیس کیے جانے والے کلائنٹ محدود اور بے کار دونوں ہو سکتے ہیں۔
عین اسی وقت پر. اگر ایک کارپوریٹ گاہک کے پاس ایسے ڈائریکٹرز ہیں جو متعدد دوسرے کلائنٹس کے درمیان بیٹھتے ہیں، تو ہر فرد کا جائزہ بڑی تصویر کو کیوں نظر انداز کرے گا۔ کیا آپ بھی ہر رشتے میں ایک ہی ڈائریکٹر کا متعدد بار جائزہ لینے جا رہے ہیں یا آپ کر سکتے ہیں۔
ایک بار کریں اور اس معلومات کو پوری تنظیم میں دوبارہ استعمال کریں؟
فائدہ ظاہر کرنے کے لیے ان کے پاس مشترکہ متعلقہ فریق ہونے کی بھی ضرورت نہیں ہے۔ اسی طرح کی صنعتیں، ملتے جلتے کلائنٹ گاہک، کیا ہوگا اگر آپ کے کلائنٹ وینڈرز/سپلائرز خود بھی کلائنٹ ہیں؟ یہ ہمیں بتاتا ہے کہ آپ کو معلومات پر کارروائی کرنے کی ضرورت ہے۔
اور ان دنوں سافٹ ویئر پر غور کرتے وقت تنظیموں کو پورے انٹرپرائز کو دیکھنے کی ضرورت کیوں ہے۔ اگر آپ کسی مسئلے کو تنہائی میں دیکھتے ہیں اور اس کا علاج کرتے ہیں، بجٹ قائم کرتے ہیں اور ہر CRM، Fincrime، Client Outreach جزو کے لیے RFPs جاری کرتے ہیں، تو آپ ختم ہو جائیں گے۔
کسی بھی ممکنہ بچت کے مقابلے میں ہر چیز کو ایک ساتھ ضم کرنے کی کوشش میں زیادہ وسائل خرچ کرنے کے ساتھ جس کی ابتدا میں امید کی گئی تھی۔ اب اسے ہر علاقے یا کاروبار کی لائن کے لیے لاگو کریں جس کو الگ بجٹ اور نگرانی مل سکتی ہے اور آپ کو 8 ورژن ملیں گے۔
ایک ہی سافٹ ویئر کا جس کو اپنے ساتھ ضم کرنے کی ضرورت ہے کیونکہ فی رقبہ بھاری تخصیص کی وجہ سے کسی بھی پیمانے کی معیشتوں کو ختم کر کے وہ حاصل کر سکتے ہیں۔
دراز میں ایک فولڈر جس کا سالانہ یا دوسری صورت میں جائزہ لینے کی ضرورت ہوتی ہے، عملے کو تربیت دینے کی ضرورت ہوتی ہے کہ اسے کیا کرنا ہے اور کب کرنا ہے۔ مکمل جائزہ (یا نئی آن بورڈنگ/اضافی پروڈکٹ/سروس/وغیرہ) کو جامع حصوں میں تقسیم کیا جا سکتا ہے جو یا
دوسرے لوگوں/ٹیموں کے ذریعہ نہیں سنبھالا جا سکتا ہے۔ اس کے بعد سسٹم اس بات کا تعین کر سکتا ہے کہ کوئی کام کب مکمل ہوتا ہے یا جب کافی ڈیٹا حاصل کیا جاتا ہے تاکہ اگلے شخص کو ان کے ان پٹ کے لیے بھیجا جا سکے۔ یہ سب کیسز اور ذیلی کیسز کے طور پر بنائے گئے ہیں۔ اس طرح سے ہر ایک عنصر
کیس کی اپنی ڈیڈ لائن، اسکیلیشن پاتھ، تفویض کرنے والے اور منظور کنندگان ہوسکتے ہیں۔ ایک بڑے کام کی بجائے جس کے لیے عملے کے رکن کو یہ جاننے کے لیے کافی تجربہ کار ہونا چاہیے کہ اندر اندر مختلف عناصر کے لیے کس کے پاس جانا ہے، اب سسٹم اس کام کو تفویض کرتا ہے۔
اور پوری کمپنی میں اس کی بروقت تکمیل کو یقینی بناتا ہے اور زیادہ سے زیادہ خودکار کاموں کے ساتھ فیصلہ سازوں کو اس بات پر توجہ مرکوز کرنے کے لیے آزاد کرتا ہے کہ کیا ضروری ہے۔
کاروباری نقطہ نظر سے یہ سب ٹھیک اور اچھا ہے۔ کام معلوم ہے اور کیا کرنے کی ضرورت ہے۔ لیکن جب ہم یہ فیصلہ کرنے کی کوشش کر رہے ہیں کہ آیا ہمیں سافٹ ویئر خود خریدنا چاہیے یا بنانا چاہیے، تو یہ چیز چیزوں میں کیسے اثر انداز ہوتی ہے؟ اچھا مان لیتے ہیں کہ متعدد ذرائع ہیں۔
متعدد سسٹمز میں ڈیٹا کا۔ توقع کی جاتی ہے کہ کوئی بھی جدید نظام API پر مبنی ہوگا اور اس میں کم کوڈ/کوڈ کی صلاحیت نہیں ہے۔ تیز اور لچکدار سافٹ ویئر کے لیے ایک معقول مفروضہ۔ ان دنوں ہر چیز کو مائیکرو سرویس کے طور پر سمجھنے کی ضرورت ہے جس سے بچنے کے لیے
پرانے سٹائل سافٹ ویئر monoliths. سافٹ ویئر کو انسٹال اور استعمال کیا جانا چاہئے کیونکہ یہ سب سے بہترین دستیاب ہے اور مستقبل میں ضرورت کے مطابق تبدیلی کو اپنانے کا ثبوت ہے۔ بہت ساری پیش کشوں کو داخل کیا جاتا ہے اور صرف برقرار رکھا جاتا ہے کیونکہ وہ بہت مشکل اور وقت طلب ہیں۔
تبدیل کرنے کے لئے. اس میں سے زیادہ تر اس وجہ سے ہے کہ قواعد سخت کوڈ شدہ ہیں، شاید خود ڈیٹا کے ساتھ جڑے ہوئے ہیں، انفارمیشن چین میں سافٹ ویئر کے ہر الگ ٹکڑے کے لیے ڈیٹا کو نہ صرف مربوط کیا جاتا ہے بلکہ متعدد بار نقل کیا جاتا ہے اور اگر آپ ایک ٹکڑے کو تبدیل کرنے کی کوشش کرتے ہیں،
پورا نظام ٹوٹ سکتا ہے۔ بہت زیادہ پرانی سوچ کا عمل، اگر یہ ٹوٹا نہیں ہے تو اسے ٹھیک نہ کریں۔ واقعی جس چیز کی ضرورت ہے وہ یہ ہے کہ ان تمام اجزاء کے ٹکڑوں کو مائیکرو سروسز بنانا، جس ڈیٹا کی ضرورت ہے اسے لینا، خودکار اصولوں کا اطلاق کرنا یا صارف کے ان پٹ/جائزے اور
اسے اگلی مائیکرو سروس تک منتقل کرنا۔ ڈیٹا کو ایک سے زیادہ جگہوں پر محفوظ نہیں کیا جانا چاہیے۔ یہ فیڈریٹ ہو سکتا ہے لیکن بیک اپ کے باہر نقل نہیں کیا جا سکتا۔ آپ کے CRM، آن بورڈنگ، KYC، کلائنٹ آؤٹ ریچ وغیرہ سسٹمز کو صرف اس ڈیٹا تک رسائی حاصل کرنی چاہیے جس کی انہیں ضرورت ہے نہ کہ
خود ڈیٹا ریپوزٹری بنیں جب تک کہ آپ نے کسی کو منتخب نہ کیا ہو۔ ایک ہی ڈیٹا کو متعدد مقامات پر نقل کرنا اور اس پر حکمرانی کرنے والے قواعد فضولیت میں ایک مشق ہے کیونکہ ہر اضافی نظام شامل کرنے سے اس میں شامل پیچیدگیوں کو کئی گنا بڑھ جائے گا۔
یہ ہمیں حتمی غور کی طرف لاتا ہے۔ چاہے آپ کے پاس سچائی/گولڈن کاپی کا واحد ذریعہ ہو یا متعدد بے کار اور مسابقتی ریکارڈز اور سسٹمز جو انہیں اپ ڈیٹ کر سکتے ہیں، آپ پھر بھی اپنے آپ کو ضرورتوں کی ایک اور پرت میں پائیں گے۔
کاروبار، دائرہ اختیار، کلائنٹ کی اقسام اور مصنوعات/خدمات۔ کسی فرد کے ساتھ کمپنی یا ٹرسٹ سے مختلف سلوک کیا جاتا ہے اور صارفین/خوردہ، تجارتی یا کارپوریٹ لائنز آف بزنس کے لحاظ سے ضروریات اور مناسبیت کے لحاظ سے مختلف ہوتا ہے۔ سب سے بنیادی مثالوں میں اگر
ہمارے پاس 10 قسم کے کلائنٹس ہیں (انفرادی - سنگل، شادی شدہ، وغیرہ، پرائیویٹ کمپنی، پبلک کمپنی، ٹرسٹ، چیریٹی، وغیرہ) اور آپ 10 علاقوں میں کام کر سکتے ہیں، اور آپ 10 قسم کی پروڈکٹس/سروسز پیش کر سکتے ہیں، ہم پہلے سے ہی ممکنہ طور پر 1000+ قواعد جو ہو سکتے ہیں۔
لاگو کیا جائے. کیا یہ اتنا آسان نہیں ہوگا کہ کسی علاقے کے لیے، کاروبار کی ایک لائن کے لیے، کسی کلائنٹ کی قسم اور مصنوعات یا خدمات کے لیے اصولوں کی وضاحت اور نظام کو اس کی بجائے ضروریات کو حل کرنے دیں؟ ڈپلیکیٹس کو ہٹانا اور ڈیٹا پوائنٹس کو دوبارہ استعمال کرنا جو پہلے تھے۔
فراہم کی. یہ آپ کے ڈیٹا لیئر سے آپ کے عمل اور قواعد کو خلاصہ کرنے کا فائدہ ہے۔
لہذا اب جب ہم سافٹ ویئر خریدنے یا بنانے کے پرانے سوال پر غور کرتے ہیں، تو ہم جانتے ہیں کہ ہمیں اومنی چینل آرکیسٹریشن، جہاں ممکن ہو پروسیس آٹومیشن، لچکدار اصول منطق، نگرانی اور آڈٹ ایبلٹی کے لیے کیس مینجمنٹ، کم کوڈ اور API پر مبنی، ایک خلاصہ کی ضرورت ہے۔
ڈیٹا لیئر اور ایک ذہین رولز انجن جو مختلف منطقی پرتوں سے وراثت میں مل سکتا ہے۔ ٹیک مارکیٹ ایسے جدت پسندوں سے بھری ہوئی ہے جو ہر اس مسئلے کو بخوشی پورا کرتے ہیں جس کے بارے میں سوچا جا سکتا ہے لیکن کس مقام پر 'شیلف سے دور' ہونے کا مطلب نہیں بنتا؟
وہ پروڈکٹس جنہیں خود بنانے کے بجائے سب کو اپنی مرضی کے مطابق اور ایک دوسرے کے ساتھ مربوط کرنے کی ضرورت ہے۔ کم کوڈ پلیٹ فارمز آپ کو اپنی ضروریات کا 80% دستیاب کر سکتے ہیں اور آپ کو صرف اس ڈیلٹا کو 20% کنفیگر کرنے کی ضرورت ہے۔ دونوں جہانوں میں سب سے بہتر کم ہے۔
کوڈ پلیٹ فارم جس کے لیے دوسروں نے دوبارہ قابل استعمال اجزاء بھی بنائے ہیں تاکہ آپ 'آف دی شیلف' پروڈکٹس کو اپنے کاروبار کے لیے ایکسلریٹر کے طور پر حاصل کر سکیں جبکہ آپ کے عملے یا تصدیق شدہ تیسرے فریق کے لیے مخصوص ضروریات کو پورا کرنے کی اہلیت بھی ہو۔
آپ کی تنظیم کو. خریدنا ہے یا تعمیر کرنا ہے؟ یہ واقعی دونوں ہونا چاہئے.
