سب کو ہیلو، میرا نام Igor Tyukachev ہے اور میں کاروباری تسلسل کا مشیر ہوں۔ آج کی پوسٹ میں ہم مشترکہ سچائیوں پر ایک طویل اور تھکا دینے والی بحث کریں گے۔ میں اپنا تجربہ شیئر کرنا چاہتا ہوں اور ان اہم غلطیوں کے بارے میں بات کرنا چاہتا ہوں جو کمپنیاں کاروبار کے تسلسل کا منصوبہ بناتے وقت کرتی ہیں۔
1. بے ترتیب RTO اور RPO
سب سے اہم غلطی جو میں نے دیکھی ہے وہ یہ ہے کہ ریکوری ٹائم (RTO) کو ہوا سے باہر نکالا جاتا ہے۔ ٹھیک ہے، پتلی ہوا سے باہر - مثال کے طور پر، SLA سے دو سال پہلے کے کچھ نمبر ہیں جو کوئی اپنے پچھلے کام کی جگہ سے لایا تھا۔ وہ ایسا کیوں کرتے ہیں؟ سب کے بعد، تمام طریقوں کے مطابق، آپ کو پہلے کاروباری عمل کے نتائج کا تجزیہ کرنا چاہیے، اور اس تجزیہ کی بنیاد پر، ہدف کی وصولی کے وقت اور قابل قبول ڈیٹا کے نقصان کا حساب لگانا چاہیے۔ لیکن اس طرح کا تجزیہ کرنے میں بعض اوقات کافی وقت لگتا ہے، بعض اوقات یہ مہنگا ہوتا ہے، بعض اوقات یہ بالکل واضح نہیں ہوتا ہے کہ کس طرح — اس بات پر زور دیں کہ کیا کرنے کی ضرورت ہے۔ اور پہلی چیز جو بہت سے لوگوں کے ذہن میں آتی ہے وہ ہے: "ہم سب بالغ ہیں اور سمجھتے ہیں کہ کاروبار کیسے کام کرتا ہے۔ آئیے وقت اور پیسہ ضائع نہ کریں! آئیے پلس یا مائنس کو جیسا کہ ہونا چاہیے۔ آپ کے سر سے باہر، پرولتاریہ آسانی کا استعمال کرتے ہوئے! آر ٹی او کو دو گھنٹے ہونے دو۔
اس سے کیا ہوتا ہے؟ جب آپ کسی مخصوص نمبر کے ساتھ مطلوبہ RTO/RPO کو یقینی بنانے کے لیے سرگرمیوں کے لیے رقم کے لیے انتظامیہ کے پاس آتے ہیں، تو اسے ہمیشہ جواز کی ضرورت ہوتی ہے۔ اگر کوئی جواز نہیں ہے تو پھر سوال یہ پیدا ہوتا ہے کہ آپ نے یہ کہاں سے حاصل کیا؟ اور جواب دینے کے لیے کچھ نہیں ہے۔ نتیجے کے طور پر، آپ کے کام پر اعتماد ختم ہو جاتا ہے.
اس کے علاوہ، بعض اوقات ان دو گھنٹے کی بحالی پر ایک ملین ڈالر لاگت آتی ہے۔ اور آر ٹی او کی مدت کا جواز پیش کرنا پیسے کا معاملہ ہے، اور اس میں بہت بڑا معاملہ ہے۔
اور آخر میں، جب آپ اپنے BCP اور/یا DR پلان کو فنکاروں کے سامنے لاتے ہیں (جو واقعتاً حادثے کے وقت دوڑ رہے ہوں گے اور اپنے بازو لہرا رہے ہوں گے)، تو وہ اسی طرح کا سوال پوچھیں گے: یہ دو گھنٹے کہاں سے آئے؟ اور اگر آپ واضح طور پر اس کی وضاحت نہیں کر سکتے ہیں، تو انہیں آپ یا آپ کی دستاویز پر اعتماد نہیں ہوگا۔
یہ نکلا کاغذ کے ٹکڑے کی خاطر، ان سبسکرائب۔ ویسے، کچھ لوگ جان بوجھ کر ایسا کرتے ہیں، محض ریگولیٹر کی ضروریات کو پورا کرنے کے لیے۔
اچھا تم سمجھ رہے ہو۔
2. ہر چیز کا علاج
کچھ لوگوں کا خیال ہے کہ ایک BCP منصوبہ تمام کاروباری عمل کو کسی بھی خطرات سے بچانے کے لیے تیار کیا گیا ہے۔ حال ہی میں، سوال "ہم اپنے آپ کو کس چیز سے بچانا چاہتے ہیں؟" میں نے جواب سنا: "سب کچھ اور زیادہ۔"
لیکن حقیقت یہ ہے کہ منصوبہ صرف تحفظ فراہم کرنا ہے۔ مخصوص کمپنی کے اہم کاروباری عمل سے مخصوص دھمکیاں لہذا، ایک منصوبہ تیار کرنے سے پہلے، خطرات کی موجودگی کا اندازہ لگانا اور کاروبار کے لیے ان کے نتائج کا تجزیہ کرنا ضروری ہے۔ یہ سمجھنے کے لیے خطرے کی تشخیص کی ضرورت ہے کہ کمپنی کن خطرات سے خوفزدہ ہے۔ عمارت کی تباہی کی صورت میں ایک تسلسل کا منصوبہ ہوگا، منظوری کے دباؤ کی صورت میں - دوسرا، سیلاب کی صورت میں - تیسرا۔ یہاں تک کہ مختلف شہروں میں دو ایک جیسی سائٹس کے بھی کافی مختلف منصوبے ہو سکتے ہیں۔
ایک BCP کے ساتھ پوری کمپنی کی حفاظت کرنا ناممکن ہے، خاص طور پر ایک بڑی کمپنی۔ مثال کے طور پر، بڑے X5 ریٹیل گروپ نے دو اہم کاروباری عملوں کے ساتھ تسلسل کو یقینی بنانا شروع کیا (ہم نے اس کے بارے میں لکھا )۔ اور پوری کمپنی کو ایک منصوبے کے ساتھ منسلک کرنا غیر حقیقی ہے؛ یہ "اجتماعی ذمہ داری" کے زمرے سے ہے، جب ہر کوئی ذمہ دار ہے اور کوئی ذمہ دار نہیں ہے۔
ISO 22301 معیار ایک پالیسی کا تصور رکھتا ہے، جس کے ساتھ، حقیقت میں، کمپنی میں تسلسل کا عمل شروع ہوتا ہے۔ یہ بیان کرتا ہے کہ ہم کس چیز کی حفاظت کریں گے اور کس چیز سے۔ اگر لوگ دوڑتے ہوئے آتے ہیں اور یہ اور اسے شامل کرنے کو کہتے ہیں، مثال کے طور پر:
- آئیے بی سی پی میں اس خطرے کو شامل کریں کہ ہمیں ہیک کیا جائے گا؟
یا کیا
- حال ہی میں، بارش کے دوران، ہماری اوپر کی منزل سیلاب میں آگئی - آئیے ایک منظر نامہ شامل کریں کہ سیلاب کی صورت میں کیا کرنا ہے؟
پھر انہیں فوری طور پر اس پالیسی کا حوالہ دیتے ہیں اور کہتے ہیں کہ ہم مخصوص کمپنی کے اثاثوں کی حفاظت کرتے ہیں اور صرف مخصوص، پہلے سے متفقہ خطرات سے، کیونکہ وہ اب ترجیح ہیں۔
اور یہاں تک کہ اگر تبدیلیوں کی تجاویز واقعی مناسب ہیں، تو پھر پالیسی کے اگلے ورژن میں ان کو مدنظر رکھنے کی پیشکش کریں۔ کیونکہ کمپنی کی حفاظت پر بہت زیادہ رقم خرچ ہوتی ہے۔ لہذا BCP پلان میں تمام تبدیلیاں بجٹ کمیٹی اور منصوبہ بندی کے ذریعے ہونی چاہئیں۔ ہم سال میں ایک بار یا کمپنی کے ڈھانچے یا بیرونی حالات میں نمایاں تبدیلیوں کے فوراً بعد کمپنی کی کاروباری تسلسل کی پالیسی کا جائزہ لینے کی تجویز کرتے ہیں (قارئین ایسا کہنے پر مجھے معاف کر دیں)۔
3. تصورات اور حقیقت
اکثر ایسا ہوتا ہے کہ BCP منصوبہ بناتے وقت مصنفین دنیا کی کچھ مثالی تصویر بیان کرتے ہیں۔ مثال کے طور پر، "ہمارے پاس دوسرا ڈیٹا سینٹر نہیں ہے، لیکن ہم ایک منصوبہ لکھیں گے جیسے ہم کرتے ہیں۔" یا کاروبار کے پاس ابھی تک انفراسٹرکچر کا کچھ حصہ نہیں ہے، لیکن ملازمین اسے اس امید کے ساتھ پلان میں شامل کریں گے کہ یہ مستقبل میں ظاہر ہوگا۔ اور پھر کمپنی حقیقت کو منصوبے پر پھیلا دے گی: دوسرا ڈیٹا سینٹر بنائیں، دیگر تبدیلیوں کی وضاحت کریں۔
بائیں طرف بنیادی ڈھانچہ ہے جو BCP سے مطابقت رکھتا ہے، دائیں طرف اصلی بنیادی ڈھانچہ ہے
یہ سب ایک غلطی ہے۔ BCP منصوبہ لکھنے کا مطلب پیسہ خرچ کرنا ہے۔ اگر آپ کوئی ایسا منصوبہ لکھتے ہیں جو ابھی کام نہیں کرتا ہے، تو آپ کو بہت مہنگے کاغذ کی ادائیگی ہوگی۔ اس سے صحت یاب ہونا ناممکن ہے، اسے جانچنا بھی ناممکن ہے۔ کام کی خاطر کام نکلتا ہے۔
آپ بہت تیزی سے ایک منصوبہ لکھ سکتے ہیں، لیکن بیک اپ انفراسٹرکچر بنانا اور تمام حفاظتی حلوں پر رقم خرچ کرنا طویل اور مہنگا ہے۔ اس میں ایک سال سے زیادہ وقت لگ سکتا ہے۔ اور یہ ہو سکتا ہے کہ آپ کے پاس پہلے سے ایک منصوبہ ہے، اور اس کے لیے بنیادی ڈھانچہ دو سالوں میں ظاہر ہو جائے گا۔ ایسے منصوبے کی ضرورت کیوں ہے؟ یہ آپ کو کس چیز سے بچائے گا؟
یہ بھی ایک خیالی بات ہے جب BCP ترقیاتی ٹیم ماہرین کے لیے یہ معلوم کرنا شروع کر دیتی ہے کہ انہیں کیا کرنا چاہیے اور کس وقت میں کرنا چاہیے۔ یہ زمرہ سے آتا ہے: "جب آپ تائیگا میں ریچھ کو دیکھتے ہیں، تو آپ کو ریچھ سے مخالف سمت میں مڑنے اور ریچھ کی رفتار سے زیادہ رفتار سے دوڑنا پڑتا ہے۔ سردیوں کے مہینوں کے دوران، آپ کو اپنی پٹریوں کو ڈھانپنے کی ضرورت ہے۔
4. ٹاپس اور جڑیں۔
چوتھی سب سے اہم غلطی منصوبہ کو یا تو بہت سطحی یا بہت تفصیلی بنانا ہے۔ ہمیں ایک سنہری مطلب کی ضرورت ہے۔ منصوبہ احمقوں کے لیے زیادہ مفصل نہیں ہونا چاہیے، لیکن یہ اتنا عام نہیں ہونا چاہیے کہ کچھ اس طرح ختم ہو جائے:
عام طور پر آسان پر
5. سیزر کو - سیزر کیا ہے، مکینک کے لیے - میکینک کیا ہے۔
اگلی غلطی پچھلی غلطی سے ہوتی ہے: ایک منصوبہ انتظامیہ کے تمام سطحوں کے لیے تمام اقدامات کو ایڈجسٹ نہیں کر سکتا۔ بی سی پی کے منصوبے عام طور پر بڑی کمپنیوں کے لیے تیار کیے جاتے ہیں جن میں بڑے مالیاتی بہاؤ ہوتے ہیں (ویسے، ہمارے مطابق اوسطاً، 48% بڑی روسی کمپنیوں کو ہنگامی حالات کا سامنا کرنا پڑا جس میں اہم مالی نقصانات کا سامنا کرنا پڑا) اور ایک کثیر سطحی انتظامی نظام۔ ایسی کمپنیوں کے لئے، یہ ایک دستاویز میں ہر چیز کو فٹ کرنے کی کوشش کرنے کے قابل نہیں ہے. اگر کمپنی بڑی اور ساختی ہے، تو اس منصوبے کے تین الگ الگ درجے ہونے چاہئیں:
- اسٹریٹجک سطح - سینئر مینجمنٹ کے لئے؛
- حکمت عملی کی سطح - درمیانی مینیجرز کے لیے؛
- اور آپریشنل سطح - ان لوگوں کے لیے جو براہ راست میدان میں شامل ہیں۔
مثال کے طور پر، اگر ہم ایک ناکام انفراسٹرکچر کی بحالی کے بارے میں بات کر رہے ہیں، تو سٹریٹجک سطح پر بحالی کے منصوبے کو فعال کرنے کا فیصلہ کیا جاتا ہے، حکمت عملی کی سطح پر عمل کے طریقہ کار کو بیان کیا جا سکتا ہے، اور آپریشنل سطح پر مخصوص کام کرنے کی ہدایات موجود ہیں۔ سامان کے ٹکڑے.
BCP بغیر بجٹ کے
ہر کوئی اپنی ذمہ داری کا علاقہ اور دوسرے ملازمین کے ساتھ روابط دیکھتا ہے۔ حادثے کے وقت، ہر کوئی ایک منصوبہ کھولتا ہے، جلدی سے اپنے حصے کو تلاش کرتا ہے اور اس پر عمل کرتا ہے. مثالی طور پر، آپ کو دل سے یاد رکھنے کی ضرورت ہے کہ کون سے صفحات کھولنے ہیں، کیونکہ بعض اوقات منٹ گنتے ہیں۔
6. کردار ادا کرنا
BCP پلان بناتے وقت ایک اور غلطی: پلان میں مخصوص نام، ای میل ایڈریس اور دیگر رابطہ کی معلومات شامل کرنے کی ضرورت نہیں ہے۔ دستاویز کے متن میں ہی، صرف غیر ذاتی کرداروں کی نشاندہی کی جانی چاہیے، اور ان کرداروں کو مخصوص کاموں کے لیے ذمہ داروں کے نام تفویض کیے جانے چاہئیں اور ان کے رابطوں کو منصوبہ کے ضمیمہ میں درج کیا جانا چاہیے۔
کیوں؟
آج، زیادہ تر لوگ ہر دو سے تین سال بعد نوکریاں بدلتے ہیں۔ اور اگر آپ پلان کے متن میں تمام ذمہ داران اور ان کے رابطوں کو لکھ دیں گے تو اسے مسلسل تبدیل کرنا پڑے گا۔ اور بڑی کمپنیوں میں، اور خاص طور پر سرکاری کمپنیوں میں، کسی بھی دستاویز میں ہر تبدیلی کے لیے ایک ٹن منظوری کی ضرورت ہوتی ہے۔
اس بات کا ذکر کرنے کی ضرورت نہیں ہے کہ اگر کوئی ہنگامی صورت حال پیش آتی ہے اور آپ کو منصوبہ بندی کے ذریعے پاگل پن سے جانا پڑتا ہے اور صحیح رابطہ تلاش کرنا پڑتا ہے، تو آپ کا قیمتی وقت ضائع ہو جائے گا۔
لائف ہیک: جب آپ کوئی ایپلیکیشن تبدیل کرتے ہیں، تو آپ کو اکثر اسے منظور کرنے کی بھی ضرورت نہیں ہوتی۔ ایک اور ٹپ: آپ پلان اپ ڈیٹ آٹومیشن سسٹم استعمال کر سکتے ہیں۔
7. ورژن کی کمی
عام طور پر وہ ایک پلان ورژن 1.0 بناتے ہیں، اور پھر تمام تبدیلیاں موڈ میں ترمیم کیے بغیر، اور فائل کا نام تبدیل کیے بغیر کرتے ہیں۔ ایک ہی وقت میں، یہ اکثر واضح نہیں ہوتا ہے کہ پچھلے ورژن کے مقابلے میں کیا تبدیلی آئی ہے۔ ورژن کی عدم موجودگی میں، منصوبہ اپنی زندگی گزارتا ہے، جس کا کسی بھی طرح سے سراغ نہیں لگایا جاتا ہے۔ کسی بھی BCP پلان کا دوسرا صفحہ ورژن، تبدیلیوں کے مصنف، اور خود تبدیلیوں کی فہرست کی نشاندہی کرے۔
اب کوئی اس کا اندازہ نہیں لگا سکتا
8. میں کس سے پوچھوں؟
اکثر کمپنیوں کے پاس BCP پلان کے لیے ذمہ دار کوئی فرد نہیں ہوتا ہے اور کاروبار کے تسلسل کے لیے کوئی الگ محکمہ نہیں ہوتا ہے۔ یہ معزز ذمہ داری CIO، اس کے نائب کو تفویض کی گئی ہے، یا اس اصول کے مطابق "آپ معلومات کی حفاظت سے نمٹتے ہیں، اس لیے یہاں BCP بھی ہے۔" نتیجے کے طور پر، منصوبہ اوپر سے نیچے تک تیار، اس پر اتفاق اور منظور کیا جاتا ہے۔
پلان کو محفوظ کرنے، اپ ڈیٹ کرنے اور اس میں موجود معلومات پر نظر ثانی کرنے کا ذمہ دار کون ہے؟ یہ تجویز نہیں کیا جا سکتا. اس کے لیے الگ ملازم رکھنا فضول ہے، لیکن موجودہ ملازمین میں سے کسی ایک کو اضافی ڈیوٹی لگانا ممکن ہے، یقیناً، کیونکہ اب ہر کوئی کارکردگی کے لیے کوشاں ہے: "آئیے اس پر لالٹین لٹکا دیں تاکہ وہ رات کو کاٹ سکے،" لیکن کیا یہ ضروری ہے؟
ہم BCP کی تشکیل کے دو سال بعد اس کے ذمہ داروں کی تلاش کر رہے ہیں۔
لہذا، یہ اکثر اس طرح ہوتا ہے: ایک منصوبہ تیار کیا گیا تھا اور دھول سے ڈھکنے کے لئے ایک طویل باکس میں ڈال دیا گیا تھا. کوئی بھی اس کی جانچ نہیں کرتا اور نہ ہی اس کی مطابقت برقرار رکھتا ہے۔ جب میں کسی گاہک کے پاس آتا ہوں تو سب سے عام جملہ جو میں سنتا ہوں وہ یہ ہے: "ایک منصوبہ ہے، لیکن یہ بہت پہلے تیار کیا گیا تھا، آیا اس کا تجربہ کیا گیا تھا، یہ معلوم نہیں ہے، ایک شبہ ہے کہ یہ کام نہیں کرتا ہے۔"
9. بہت زیادہ پانی
ایسے منصوبے ہیں جن میں تعارف پانچ صفحات پر مشتمل ہے، جس میں کمپنی کے کام کے بارے میں معلومات کے ساتھ، پراجیکٹ کے تمام شرکاء کا شکریہ اور ضروری شرائط کی تفصیل شامل ہے۔ جب تک آپ دسویں صفحے پر نیچے جائیں گے، جہاں مفید معلومات موجود ہیں، آپ کا ڈیٹا سینٹر پہلے ہی بھر چکا ہے۔
جب آپ اس وقت تک پڑھنے کی کوشش کر رہے ہیں، اگر آپ کے ڈیٹا سینٹر میں سیلاب آ جائے تو آپ کو کیا کرنا چاہیے؟
تمام کارپوریٹ "پانی" کو الگ دستاویز میں رکھیں۔ منصوبہ خود انتہائی مخصوص ہونا چاہیے: اس کام کا ذمہ دار شخص یہ کرتا ہے، وغیرہ۔
10. ضیافت کس کے خرچ پر ہے؟
اکثر، منصوبہ سازوں کو کمپنی کی اعلیٰ انتظامیہ کی طرف سے تعاون حاصل نہیں ہوتا ہے۔ لیکن درمیانی انتظامیہ کی طرف سے تعاون حاصل ہے جو کاروبار کے تسلسل کو منظم کرنے کے لیے ضروری بجٹ اور وسائل کا انتظام نہیں کرتے یا ان کے پاس نہیں ہے۔ مثال کے طور پر، آئی ٹی ڈیپارٹمنٹ اپنے بجٹ کے اندر اپنا BCP منصوبہ بناتا ہے، لیکن CIO کمپنی کی پوری تصویر نہیں دیکھتا۔ میری پسندیدہ مثال ویڈیو کانفرنسنگ ہے۔ جب سی ای او کی ویڈیو کانفرنسنگ کام نہیں کرے گی تو وہ کس کو نکالے گا؟ CIO جس نے "فراہم نہیں کیا۔" لہذا، CIO کے نقطہ نظر سے، کمپنی میں سب سے اہم چیز کیا ہے؟ جس چیز کے لیے لوگ اس سے ہمیشہ "محبت" کرتے ہیں: ویڈیو کانفرنسنگ، جو فوری طور پر کاروباری اہم نظام میں بدل جاتی ہے۔ اور کاروباری نقطہ نظر سے - ٹھیک ہے، کوئی VKS نہیں، ذرا سوچئے، ہم فون پر بات کریں گے، جیسے بریزنیف کے تحت...
اس کے علاوہ، آئی ٹی ڈیپارٹمنٹ عام طور پر یہ سوچتا ہے کہ کسی آفت کی صورت میں اس کا بنیادی کام کارپوریٹ آئی ٹی سسٹم کے آپریشن کو بحال کرنا ہے۔ لیکن کبھی کبھی آپ کو ایسا کرنے کی ضرورت نہیں ہے! اگر کسی انتہائی مہنگے پرنٹر پر کاغذ کے ٹکڑوں کی پرنٹنگ کی صورت میں کوئی کاروباری عمل ہو، تو آپ کو اسپیئر کے طور پر ایسا دوسرا پرنٹر نہیں خریدنا چاہیے اور خرابی کی صورت میں اسے اپنے پاس رکھنا چاہیے۔ ہاتھ سے کاغذ کے ٹکڑوں کو عارضی طور پر رنگ دینا کافی ہو سکتا ہے۔
اگر ہم IT کے اندر مسلسل تحفظ کی تعمیر کر رہے ہیں، تو ہمیں سینئر مینجمنٹ اور کاروباری نمائندوں کی حمایت حاصل کرنی چاہیے۔ بصورت دیگر، آئی ٹی ڈیپارٹمنٹ میں داخل ہونے کے بعد، آپ مسائل کی ایک خاص حد کو حل کر سکتے ہیں، لیکن تمام ضروری نہیں۔
جب صرف IT ڈیپارٹمنٹ کے پاس DR کے منصوبے ہوتے ہیں تو صورتحال ایسی ہی نظر آتی ہے۔
10. کوئی ٹیسٹنگ نہیں۔
اگر کوئی منصوبہ ہے تو اسے جانچنے کی ضرورت ہے۔ ان لوگوں کے لیے جو معیارات سے واقف نہیں ہیں، یہ بالکل واضح نہیں ہے۔ مثال کے طور پر، آپ کے پاس ہر جگہ "ایمرجنسی ایگزٹ" کے نشانات لٹک رہے ہیں۔ لیکن یہ بتاؤ کہ تمہاری آگ کی بالٹی، کانٹا اور بیلچہ کہاں ہے؟ فائر ہائیڈرنٹ کہاں ہے؟ آگ بجھانے والا آلہ کہاں ہونا چاہیے؟ لیکن یہ سب کو معلوم ہونا چاہیے۔ دفتر میں داخل ہوتے وقت آگ بجھانے والے آلات کو تلاش کرنا ہمارے لیے بالکل بھی منطقی نہیں لگتا۔
شاید اس منصوبے کو جانچنے کی ضرورت کا ذکر پلان میں ہی ہونا چاہیے، لیکن یہ ایک متنازعہ فیصلہ ہے۔ کسی بھی صورت میں، کسی منصوبے کو صرف اسی صورت میں کام کرنے پر غور کیا جا سکتا ہے جب اس کا کم از کم ایک بار تجربہ کیا گیا ہو۔ جیسا کہ اوپر ذکر کیا گیا ہے، میں اکثر سنتا ہوں: "ایک منصوبہ ہے، تمام بنیادی ڈھانچہ تیار ہے، لیکن یہ حقیقت نہیں ہے کہ سب کچھ اسی طرح کام کرے گا جیسا کہ پلان میں لکھا ہے۔ کیونکہ انہوں نے اس کی جانچ نہیں کی۔ کبھی نہیں"۔
آخر میں
کچھ کمپنیاں اپنی تاریخ کا تجزیہ کر سکتی ہیں تاکہ یہ سمجھ سکیں کہ کس قسم کی پریشانیوں کا امکان ہے اور ان کے کتنے امکانات ہیں۔ تحقیق اور تجربہ بتاتا ہے کہ ہم ہر چیز سے خود کو محفوظ نہیں رکھ سکتے۔ گندگی، جلد یا بدیر، کسی بھی کمپنی کے ساتھ ہوتا ہے۔ ایک اور چیز یہ ہے کہ آپ اس یا اس سے ملتی جلتی صورتحال کے لیے کتنے تیار ہوں گے اور کیا آپ اپنے کاروبار کو بروقت بحال کر پائیں گے۔
کچھ لوگوں کا خیال ہے کہ تسلسل اس بارے میں ہے کہ ہر طرح کے خطرات کو کیسے ختم کیا جائے تاکہ وہ عملی شکل نہ اختیار کر سکیں۔ نہیں، بات یہ ہے کہ خطرات لاحق ہوں گے، اور ہم اس کے لیے تیار ہوں گے۔ فوجیوں کو جنگ میں سوچنے کی نہیں بلکہ عمل کرنے کی تربیت دی جاتی ہے۔ BCP پلان کے ساتھ بھی ایسا ہی ہے: یہ آپ کو اپنے کاروبار کو جلد از جلد بحال کرنے کی اجازت دے گا۔
واحد سامان جس میں BCP کی ضرورت نہیں ہے۔
ایگور ٹیوکاچیف،
بزنس کنٹینیوٹی کنسلٹنٹ
سینٹر فار ڈیزائن آف کمپیوٹنگ سسٹم
جیٹ انفو سسٹمز
ماخذ: www.habr.com