বিষয় 1.1 — অপারেটিং মডেল

এক বাক্যে: একটি টার্গেট অপারেটিং মডেল (TOM) হলো আপনার প্রতিষ্ঠানের কৌশল কীভাবে মূল্য-প্রবাহ, সামর্থ্য, দল, গভর্ন্যান্স, প্রযুক্তি, ডেটা ও সরবরাহকারীদের মধ্য দিয়ে প্রবাহিত হয়ে ডিজিটাল স্বাস্থ্য ও পরিচর্যার ফলাফল দেয়, তার সুচিন্তিত নকশা। এর আকার ঠিক হলো কি না তার ওপর নির্ভর করে, পরবর্তী সবকিছু দ্রুত ও নিরাপদ হবে, নাকি ধীর ও ভঙ্গুর।

স্বাস্থ্য ও পরিচর্যায় কেন এটি গুরুত্বপূর্ণ#

বেশির ভাগ ডিজিটাল স্বাস্থ্য প্রতিষ্ঠান প্রতিভা বা প্রযুক্তির অভাবে ব্যর্থ হয় না; ব্যর্থ হয় কারণ তাদের অপারেটিং মডেল তাদের বিরুদ্ধে লড়ে। অর্থায়ন বাঁধা থাকে সময়-সীমিত প্রকল্পে, সিদ্ধান্তের অধিকার অস্পষ্ট, আর প্রতিটি দল একই লগইন, ইন্টিগ্রেশন ও অডিটের নল আবার তৈরি করে। ফল: জনগণের অর্থে নকল খরচ, অসংগত ক্লিনিক্যাল নিরাপত্তা এবং এমন সেবা যা একটি সমন্বিত পরিচর্যা ব্যবস্থা (ICS) জুড়ে তথ্য ভাগ করতে পারে না।

এই ক্ষেত্রে অপারেটিং মডেল স্বতন্ত্র, কারণ তাকে পরস্পরবিরোধী কল্যাণের মধ্যে মিল ঘটাতে হয়। সার্বভৌম প্রতিষ্ঠানগুলোর, যেমন ট্রাস্ট, স্থানীয় কর্তৃপক্ষ, জিপি প্র্যাকটিসের, স্বায়ত্তশাসন মানার জন্য তাকে যথেষ্ট ফেডারেটেড হতে হয়, অথচ তাদের জুড়ে একজন রোগীকে একটি নিরাপদ অভিজ্ঞতা দিতে যথেষ্ট সুসংগতও হতে হয়। ডাউনটাইম পরিচর্যাকে প্রভাবিত করতে পারে বলে তাকে চালানো (ক্লিনিক্যাল সিস্টেম নিরাপদে সচল রাখা) ও পরিবর্তন (সেগুলোর উন্নয়ন)-এর মধ্যে ভারসাম্য রাখতে হয়। আর তাকে আনুপাতিকভাবে ব্যয় করতে হয়: জনগণের জবাবদিহিতা ও ক্লিনিক্যাল নিরাপত্তার জন্য যথেষ্ট ভারী আশ্বাস, অথচ পুনরাবৃত্তির গলা চেপে না ধরার মতো হালকা। TOM হলো সেই জায়গা, যেখানে এই ট্রেড-অফগুলো দৈবের হাতে না ছেড়ে স্পষ্ট করা হয়।

মূল ধারণা#

একটি অপারেটিং মডেল-এর স্তর। একটি কার্যকর TOM হলো একটি স্তূপ, যার প্রতিটি স্তর তার ওপরের স্তরকে সেবা দেয়:

  • কৌশল ও ফলাফল: পরিমাপযোগ্য জনগোষ্ঠী ও সেবার ফলাফল, যা উন্নত করার জন্য আপনি আছেন (প্রায়ই OKR হিসেবে প্রকাশিত; বিষয় 1.3 — প্রমাণ-চালিত সিদ্ধান্ত দেখুন)।
  • মূল্য-প্রবাহ: ব্যবহারকারীর কাছে মূল্য পৌঁছে দেওয়া প্রান্ত থেকে প্রান্ত পর্যন্ত প্রবাহ, যেমন "একজন রোগীকে রেফার, ট্রিয়াজ ও চিকিৎসা করা", যা সংগঠিত নাগরিকের যাত্রাকে ঘিরে, সাংগঠনিক চার্টকে ঘিরে নয়।
  • সামর্থ্য: যা যা করতে আপনাকে সক্ষম হতে হবে (পরিচয়, অ্যাপয়েন্টমেন্ট বুকিং, ক্লিনিক্যাল নথিকরণ, বিশ্লেষণ)। সমাধান বদলালেও সামর্থ্য স্থিতিশীল থাকে।
  • দল: সামর্থ্য ও মূল্য-প্রবাহ সরবরাহের জন্য সংগঠিত মানুষ (নিচে Team Topologies দেখুন)।
  • গভর্ন্যান্স ও সিদ্ধান্তের অধিকার: কে কী সিদ্ধান্ত নেয় এবং আশ্বাস কীভাবে প্রয়োগ হয়।
  • প্রযুক্তি ও ডেটা: যেসব প্ল্যাটফর্ম, মান ও ডেটা আর্কিটেকচারের ওপর দলগুলো গড়ে ওঠে।
  • সরবরাহকারী: যে বাজার থেকে আপনি কেনেন এবং তা কীভাবে পরিচালনা করেন।

ওপর থেকে নিচে নকশা (কৌশল → মূল্য-প্রবাহ → সামর্থ্য) দল ও প্রযুক্তিকে পুরোনো কাঠামোর বদলে ফলাফলের সঙ্গে সুসংগত রাখে।

কেন্দ্রীভূত বনাম ফেডারেটেড বনাম প্ল্যাটফর্ম মডেল। একটি কেন্দ্রীভূত মডেল ডেলিভারিকে একটি দল বা স্বাধীন সংস্থায় কেন্দ্রীভূত করে: সামঞ্জস্যপূর্ণ ও মানসম্মত করতে সস্তা, কিন্তু বাধার কারণ এবং প্রায়ই স্থানীয় প্রয়োজন থেকে দূরে। একটি ফেডারেটেড মডেল ডেলিভারি ট্রাস্ট ও এলাকাগুলোর হাতে অর্পণ করে: সাড়াশীল ও স্থানীয়ভাবে মালিকানাধীন, কিন্তু নকল ও বিচ্যুতির প্রবণ। একটি প্ল্যাটফর্ম মডেল হলো মিলনকারী ছক: একটি কেন্দ্রীয় দল ভাগ করা, পুনর্ব্যবহারযোগ্য সামর্থ্য (পরিচয়, আন্তঃকার্যক্ষমতা, হোস্টিং, ডিজাইন সিস্টেম) একটি প্ল্যাটফর্ম হিসেবে দেয়, আর ফেডারেটেড দলগুলো তার ওপর গতিতে গড়ে। বেশির ভাগ পরিপক্ব স্বাস্থ্যব্যবস্থা "প্ল্যাটফর্ম আর ফেডারেশন"-এ গিয়ে মেলে।

Team Topologies। এই কাঠামো চার ধরনের দলের নাম দেয়: স্ট্রিম-অ্যালাইনড (একটি মূল্য-প্রবাহের মালিক), প্ল্যাটফর্ম (স্বয়ংসেবা সামর্থ্য প্রদানকারী), এনাবলিং (অন্যদের একটি সামর্থ্যে এগিয়ে নেওয়ার কোচিং) এবং জটিল-উপব্যবস্থা (অ্যালগরিদমের মতো গভীর বিশেষজ্ঞ কাজ), এবং তাদের মধ্যে কম-ঘর্ষণের মিথস্ক্রিয়ার ওপর জোর দেয়। এটি প্ল্যাটফর্ম মডেলের সঙ্গে পরিষ্কারভাবে মেলে: প্ল্যাটফর্ম দলগুলো স্ট্রিম-অ্যালাইনড দলগুলোর মানসিক ভার কমায়, যাতে তারা ব্যবহারকারী ও ক্লিনিক্যাল মূল্যে মনোযোগ দিতে পারে।

চালানো বনাম পরিবর্তন। চালানো হলো লাইভ সেবাকে নিরাপদ ও সহজলভ্য রাখা; পরিবর্তন হলো সেগুলো উন্নত করা বা গড়া। যে প্রোডাক্ট দল একটি সেবা একই সঙ্গে গড়ে ও চালায় ("আপনি গড়লে আপনিই চালান") তারা ফিডব্যাক লুপ বন্ধ করে এবং নিরাপত্তা বাড়ায়, কিন্তু ভারসাম্যের জন্য সততার সঙ্গে অর্থায়ন করতে হয়; পরিবর্তনের অর্থায়নের জন্য চালানোকে অনাহারে রাখাই ক্লিনিক্যাল সিস্টেম ক্ষয়ে যাওয়ার পথ।

সবচেয়ে পাতলা কার্যকর প্ল্যাটফর্ম (TVP)। Team Topologies থেকে: একটি প্ল্যাটফর্ম হওয়া উচিত স্ট্রিম দলগুলোর জন্য ঘর্ষণ সত্যিই কমায় এমন ভাগ করা সেবার ক্ষুদ্রতম সংকলন, তার বেশি নয়। অতিরিক্ত গড়া প্ল্যাটফর্ম নিজেই নিজের বাধা ও নিজের লিগ্যাসি হয়ে ওঠে। প্রত্যেক দলের সত্যিই প্রয়োজন এমন অল্প কয়েকটি সামর্থ্য (প্রমাণীকরণ, একটি আন্তঃকার্যক্ষমতা স্তর, হোস্টিং, একটি ডিজাইন সিস্টেম) দিয়ে শুরু করুন এবং কেবল প্রমাণিত চাহিদায় বাড়ুন।

শ্রেষ্ঠ চর্চা#

  1. সাংগঠনিক চার্ট থেকে ওপরে নয়, ফলাফল থেকে নিচে মডেল নকশা করুন। আপনাকে যেসব জনগোষ্ঠী ও সেবার ফলাফল নাড়াতে হবে তা দিয়ে শুরু করুন, সেগুলো যেসব মূল্য-প্রবাহ সরবরাহ করে তা বের করুন, তারপরই কেবল দল ও প্রযুক্তি নকশা করুন। বিদ্যমান স্তরক্রমে নোঙর করা TOM কেবল বর্তমান সাইলোগুলোকেই স্বয়ংক্রিয় করে।

  2. প্ল্যাটফর্ম-আর-ফেডারেশন আকার গ্রহণ করুন। ভাগ করা সামর্থ্য কেন্দ্রীয়ভাবে স্বয়ংসেবা প্ল্যাটফর্ম হিসেবে দিন, এবং ট্রাস্ট ও এলাকার স্ট্রিম-অ্যালাইনড দলগুলোকে তার ওপর গড়তে দিন। এতে নিরাপত্তা ও আন্তঃকার্যক্ষমতায় জাতীয় সামঞ্জস্য এবং স্থানীয় গতি ও মালিকানা, দুটোই মেলে, যে মিলন এই ক্ষেত্র দাবি করে।

  3. প্রকল্প নয়, প্রোডাক্টে অর্থায়ন করুন। অর্থ সময়-সীমিত প্রকল্প থেকে মূল্য-প্রবাহের সঙ্গে সারিবদ্ধ স্থায়ীভাবে অর্থায়িত প্রোডাক্ট দলগুলোতে সরান। প্রকল্প অর্থায়ন দলগুলোকে ঠিক সেই মুহূর্তে ভেঙে ফেলতে বাধ্য করে, যখন তারা ক্ষেত্রটি শিখে ফেলেছে; প্রোডাক্ট অর্থায়ন স্বাস্থ্যসেবার প্রয়োজনীয় নিরাপত্তা-জ্ঞান ও পুনরাবৃত্তি টিকিয়ে রাখে (বিষয় 5.0 — প্রোডাক্ট-চালিত কাজ দেখুন)।

  4. ব্যয় নিয়ন্ত্রণকে আনুপাতিক ও ধাপে ধাপে করুন। প্রমাণের সঙ্গে যুক্ত ধাপে ধাপে অর্থায়ন ব্যবহার করুন: পুরো প্রোগ্রাম আগেই অনুমোদন না করে ডিসকভারি, আলফা, বিটা ও লাইভ গেটে অর্থ ছাড়ুন। GDS-ধাঁচের ব্যয় নিয়ন্ত্রণ ও NHS আশ্বাস-পথ অপ্রমাণিত ধারণায় বড় ডুবে যাওয়া খরচ ঠেকাতে আছে; সেগুলো ঝুঁকি ও মূল্য অনুযায়ী মাপা সীমা হিসেবে প্রয়োগ করুন, সর্বব্যাপী আমলাতন্ত্র হিসেবে নয়।

  5. একটি RACI বা RAPID মানচিত্র দিয়ে সিদ্ধান্তের অধিকার স্পষ্ট করুন। অস্পষ্ট কর্তৃত্ব আটকে যাওয়া ডেলিভারির সবচেয়ে সাধারণ কারণ। প্রতিটি গুরুত্বপূর্ণ সিদ্ধান্ত-ধরনের জন্য নাম দিন কে দায়িত্বশীল/জবাবদিহিকারী/পরামর্শদাতা/অবহিত (RACI), অথবা কে সুপারিশ করে, সম্মতি দেয়, সম্পাদন করে, মতামত দেয় এবং সিদ্ধান্ত নেয় (RAPID)। এটি প্রকাশ করুন, যাতে দলগুলো যেসব সিদ্ধান্ত নেওয়ার ক্ষমতা তাদের আছে সেগুলো ঊর্ধ্বতনে পাঠানো বন্ধ করে।

  6. প্ল্যাটফর্ম পাতলা ও চাহিদা-চালিত রাখুন। ভাগ করা সামর্থ্য কেবল তখনই গড়ুন, যখন দুই বা ততোধিক দল প্রদর্শনযোগ্যভাবে একই জিনিস চায়, এবং প্ল্যাটফর্মকে নিজস্ব ব্যবহারকারীসহ (অভ্যন্তরীণ দলগুলো) একটি প্রোডাক্ট হিসেবে দেখুন। একটি বিশাল প্ল্যাটফর্ম আগে থেকে গড়ার তাড়না প্রতিহত করুন; সবচেয়ে পাতলা কার্যকর প্ল্যাটফর্ম গ্রহণের মাধ্যমে নিজের পরিধি অর্জন করে।

  7. সরবরাহকারীদের মডেলের বাইরে নয়, অংশ হিসেবে পরিচালনা করুন। সুচিন্তিতভাবে ঠিক করুন কোন সামর্থ্য কৌশলগত (গড়ুন/মালিক হোন) আর কোনটি পণ্য-সামগ্রী (কিনুন), মূল ক্লিনিক্যাল ডেটায় একক-সরবরাহকারী লক-ইন এড়ান, এবং চুক্তিতে উন্মুক্ত মান ও প্রস্থানের অধিকার চাইুন। আপনার সরবরাহকারীরা আপনার অপারেটিং মডেলের একটি স্তর, এবং তাদের কাজের পদ্ধতি আপনার সঙ্গে সামঞ্জস্যপূর্ণ হতে হবে।

  8. সিদ্ধান্তের অধিকার স্পষ্ট করুন। অপারেটিং মডেল কেবল তখনই কাজ করে যখন মানুষ জানে কে কী সিদ্ধান্ত নেয়: কোন সিদ্ধান্ত প্রোডাক্ট দলের, কোনটি ক্লিনিক্যাল-নিরাপত্তা কর্তৃপক্ষের, আর কোনটি বোর্ডে পৌঁছাতে হবে। সিদ্ধান্তের অধিকার মানচিত্রে আঁকুন এবং প্রতিটি সিদ্ধান্ত সবচেয়ে নিচের সেই স্তরে ঠেলে দিন যা তা নিরাপদে ধারণ করতে পারে, যাতে অপ্রয়োজনীয় ঊর্ধ্বতন-প্রেরণে ডেলিভারি দম আটকে না যায়। অস্পষ্ট কর্তৃত্ব ধীর, আত্মরক্ষামূলক ডেলিভারির অন্যতম সাধারণ কারণ।

  9. অপারেটিং মডেলকে এমন একটি প্রোডাক্ট ভাবুন যাকে আপনি বিবর্তিত করেন। একটি টার্গেট অপারেটিং মডেল একবার ঠিক করে দেয়ালে ঝোলানোর জিনিস নয়; চাহিদা, প্রযুক্তি ও অংশীদারিত্ব বদলালে তা পরীক্ষা করুন এবং প্রমাণের ভিত্তিতে মানিয়ে নিন। কয়েকটি সংকেত দেখুন: কাজের প্রবাহ, সিদ্ধান্ত-নিতে-সময়, পুনঃকাজ ও দলের স্বাস্থ্য, এবং কাঠামো যখন প্রদর্শনযোগ্যভাবে বাধা হচ্ছে তখন তা বদলান, পুনর্গঠনের ফ্যাশনের প্রতিক্রিয়ায় নয়।

দলের সঙ্গে আলোচনার প্রশ্ন#

  1. আমাদের অপারেটিং মডেল কি ফলাফল ও মূল্য-প্রবাহ থেকে নিচে নকশা করা, নাকি তা কেবল আমাদের বিদ্যমান সাংগঠনিক চার্ট ও তার সাইলোগুলোকে স্বয়ংক্রিয় করেছে? এই প্রশ্ন বিষয়ের কেন্দ্রীয় সতর্কতায় যায়: বর্তমান স্তরক্রমে নোঙর করা TOM কেবল আপনাদের ইতিমধ্যে থাকা সাইলোগুলোকে দৃঢ় করে, তাই যেকোনো পুনর্গঠনের আগে এটি টেবিলে রাখা উচিত। স্বাস্থ্য ও পরিচর্যার ক্ষেত্রে এটি গুরুত্বপূর্ণ, কারণ মূল্য-প্রবাহ সার্বভৌম প্রতিষ্ঠানগুলো জুড়ে নাগরিকের যাত্রা (রেফার, ট্রিয়াজ, চিকিৎসা) অনুসরণ করে, আর সাংগঠনিক চার্ট অনুসরণ করে প্রাতিষ্ঠানিক সীমানা, এবং পরেরটির ওপর গড়া মডেল জনগণের অর্থে খণ্ডিত, আন্তঃকার্যক্ষমতাহীন সেবা তৈরি করতেই থাকবে। সততার সঙ্গে বিতর্কের টানাপোড়েন হলো, ফলাফল থেকে ওপর-নিচ নকশা সত্যিই বিঘ্নকারী: তা বিভাগীয় মালিকানা, বাজেট ও রিপোর্টিং লাইন কেটে দেয়, যেগুলোর চারপাশে জ্যেষ্ঠ মানুষরা তাঁদের কর্মজীবন গড়েছেন, তাই ঠিকমতো করার প্রকৃত রাজনৈতিক মূল্য আছে। নিজেদের মূর্তভাবে পরীক্ষা করুন: আপনার শীর্ষ তিনটি ফলাফলের নাম বলুন এবং অনুসরণ করুন আপনার প্রকৃত দলের সীমানা ও অর্থায়নের লাইন সেই মূল্য-প্রবাহগুলো অনুসরণ করে, নাকি বিভাগগুলো; দলগুলো যদি পরিষ্কারভাবে বিভাগের সঙ্গে মেলে, সেটাই আপনার উত্তর। ভালো, সৎ উত্তর স্বীকার করে মডেলটি কোথায় সাংগঠনিক-চার্টের আকৃতির, অন্তত একটি মূল্য-প্রবাহ চিহ্নিত করে যা বর্তমানে ক্ষতির জন্য সাইলোগুলোর মধ্যে বিভক্ত, এবং প্রতিষ্ঠান কোন কাঠামোগত সীমানা নতুন করে আঁকতে ইচ্ছুক সে বিষয়ে বাস্তববাদী।

  2. আমাদের সবচেয়ে পাতলা কার্যকর প্ল্যাটফর্মে কী থাকা উচিত, এবং আমরা কীভাবে একে অতিরিক্ত গড়ে বাধায় পরিণত হতে বা অপর্যাপ্ত গড়ে প্রতিটি দলকে একই নল আবার গড়তে বাধ্য হতে দেওয়া ঠেকাব? প্ল্যাটফর্ম-আর-ফেডারেশন আকার কেবল তখনই কাজ করে যখন প্ল্যাটফর্ম পাতলা ও চাহিদা-চালিত থাকে, এবং এই প্রশ্ন দলকে বিষয়ের নাম দেওয়া দুটি ব্যর্থতার ধরনের মুখোমুখি করে: যে বিশাল প্ল্যাটফর্ম নিজেই নিজের লিগ্যাসি বাধা হয়ে ওঠে, এবং তার অনুপস্থিতি যা প্রতিটি দলকে লগইন, ইন্টিগ্রেশন ও অডিট আবার গড়তে বাধ্য করে। এটি গুরুত্বপূর্ণ, কারণ একটি ICS-এ প্ল্যাটফর্ম কার্যত ভাগ করা অবকাঠামো (পরিচয়, একটি FHIR আন্তঃকার্যক্ষমতা স্তর, নিরাপত্তা-ভিত্তিসহ হোস্টিং, একটি ডিজাইন সিস্টেম), এবং এর পরিধি ভুল হলে প্রতিটি স্ট্রিম দলে খরচ বা ঘর্ষণ গুণিত হয়। বিতর্কের ট্রেড-অফ হলো সময় ও প্রমাণ: খুব আগে গড়লে আপনি ভুল অনুমান করে বাধা তৈরি করেন; খুব দেরিতে গড়লে নকল ইতিমধ্যেই শক্ত হয়ে গেছে, তাই "দুই বা ততোধিক দল প্রদর্শনযোগ্যভাবে একই জিনিস চায়" পরীক্ষাটি মূল কথা, এবং দলের যাচাই করা উচিত তারা আসলে তা প্রয়োগ করে নাকি কেবল যা স্পষ্টত কেন্দ্রীয় মনে হয় তাই গড়ে। বর্তমানে আপনি কী প্ল্যাটফর্ম হিসেবে দেখছেন আর দলগুলো কী আবার গড়ছে তা দেখুন, এবং জিজ্ঞাসা করুন প্ল্যাটফর্ম নিজস্ব অভ্যন্তরীণ ব্যবহারকারী ও SLA-সহ একটি প্রোডাক্ট হিসেবে চালানো হয়, নাকি এমন একটি সারি হিসেবে যার পেছনে সবাই অপেক্ষা করে। সৎ উত্তর আজ দুই-দল পরীক্ষা পাস করা নির্দিষ্ট সামর্থ্যগুলোর নাম নেয়, বাকিটা আগে থেকে গড়ার প্রলোভন প্রতিহত করে, এবং প্ল্যাটফর্ম দলের অভ্যন্তরীণ ব্যবহারকারীদের প্রকৃত সেবা-স্তরসহ প্রকৃত গ্রাহক হিসেবে দেখতে প্রতিশ্রুতিবদ্ধ হয়।

  3. আমাদের সিদ্ধান্তের অধিকার কোথায় সত্যিই অস্পষ্ট, এবং দলগুলো আজ কী ঊর্ধ্বতনে পাঠাচ্ছে যা তাদের নিজেরাই সিদ্ধান্ত নেওয়ার ক্ষমতায়ন থাকা উচিত? অস্পষ্ট কর্তৃত্বকে আটকে যাওয়া ডেলিভারির সবচেয়ে সাধারণ কারণ বলা হয়েছে, তাই এই প্রশ্ন সেই প্রতিদিনের ঘর্ষণ সামনে আনে যা একটি প্রকাশিত RACI বা RAPID মানচিত্র দূর করার জন্য। একটি ফেডারেটেড স্বাস্থ্যব্যবস্থায় এটি তীব্রভাবে গুরুত্বপূর্ণ, যেখানে এলাকা দল, একটি ICS ডিজিটাল বোর্ড, ক্লিনিক্যাল নিরাপত্তা ও তথ্য গভর্ন্যান্স সবার একটি সিদ্ধান্তের ওপর বৈধ দাবি আছে, এবং অস্পষ্ট সীমানার অর্থ হয় সবকিছু ঊর্ধ্বতনে যায় অথবা, আরও খারাপ, কেউ সিদ্ধান্ত ভুল না হওয়া পর্যন্ত তার মালিক হয় না। অনুসন্ধানের মতো টানাপোড়েন হলো, সিদ্ধান্ত অর্পণ করতে সীমারেখার মধ্যে দলগুলোকে বিশ্বাস করতে হয়, এবং জ্যেষ্ঠ নেতারা ও বোর্ড প্রায়ই ঠিক সেখানেই প্রতিরোধ করেন যেখানে ক্লিনিক্যাল নিরাপত্তা বা জনগণের অর্থ জড়িত, অথচ সেই বিশ্বাস আটকে রাখাই ঊর্ধ্বতন-প্রেরণের জট সৃষ্টির প্রথম কারণ। বিষয়টি মূর্ত করুন শেষ পাঁচটি ঊর্ধ্বতনে যাওয়া সিদ্ধান্ত তালিকাভুক্ত করে এবং প্রতিটির জন্য জিজ্ঞাসা করে কার সিদ্ধান্ত নেওয়া উচিত ছিল এবং কোন সীমারেখা তাঁকে তা করতে দিত; নকশা সাধারণত অল্প কয়েকটি বারবার ঘটা অস্পষ্ট সিদ্ধান্ত-ধরন প্রকাশ করে। ভালো উত্তর কে কী সিদ্ধান্ত নেয় তার একটি নির্দিষ্ট, প্রকাশযোগ্য বিবৃতি তৈরি করে, যা প্ল্যাটফর্ম মান, সেবা নকশা ও ক্লিনিক্যাল-নিরাপত্তা অনুমোদনকে আলাদা করে, এবং প্রতিষ্ঠান কোন সিদ্ধান্ত সত্যিই অর্পণ করতে ইচ্ছুক আর কোনটি কেন্দ্রীয় রাখবে সে বিষয়ে সৎ।

  4. আমরা কি সততার সঙ্গে চালানো ও পরিবর্তনে অর্থায়ন করছি, নাকি নতুন ফিচারের খরচ জোগাতে নীরবে লাইভ-সেবা পরিচালনাকে অনাহারে রাখছি? বিষয়টি স্পষ্ট করে বলে, পরিবর্তনের অর্থায়নে চালানোকে অনাহারে রাখাই ক্লিনিক্যাল সিস্টেম ক্ষয়ের পথ, এবং এই প্রশ্ন ভারসাম্যকে প্রকাশ্যে আনে, কোনো বিভ্রাট বা নিরাপত্তা ঘটনা আপনার হয়ে তা করার আগেই। স্বাস্থ্য ও পরিচর্যায় এটি গুরুত্বপূর্ণ, কারণ "চালানো" অফিসের বাড়তি খরচ নয়: তা পরিচর্যার মুহূর্তে চিকিৎসকরা যেসব সিস্টেমের ওপর নির্ভর করেন তাদের সহজলভ্যতা, তাই ক্ষয়প্রাপ্ত চালানোর বাজেট ডাউনটাইম হিসেবে দেখা দেয় যা কেবল বিরক্ত ব্যবহারকারী নয়, রোগীদেরও প্রভাবিত করতে পারে। ট্রেড-অফ অস্বস্তিকর, কারণ পরিবর্তন দৃশ্যমান ও উদযাপিত, আর চালানো ব্যর্থ না হওয়া পর্যন্ত অদৃশ্য, তাই বোর্ড ও রোডম্যাপ স্বাভাবিকভাবেই নতুনের দিকে ঝুঁকে; "আপনি গড়লে আপনিই চালান" মডেল ফিডব্যাক লুপ বন্ধ রেখে সাহায্য করে, কিন্তু কেবল তখনই যখন দলের চালানোর সময় নামমাত্র বরাদ্দ করে তারপর লুট না করে সত্যিই সুরক্ষিত থাকে। বিষয়টি মূর্ত করুন গত ত্রৈমাসিকে প্রতিটি প্রোডাক্ট দলের সামর্থ্যের কত অংশ সেবাকে নিরাপদ ও সহজলভ্য রাখতে গিয়েছিল তা পরিকল্পিতের বিপরীতে দেখে, এবং চালানোর কাজ ট্র্যাক ও মূল্যায়িত হয়, নাকি বাধা হিসেবে গণ্য। সৎ উত্তর আজ কোথায় চালানো কম-অর্থায়িত তা নাম ধরে বলে, একটি বাস্তবসম্মত চালানোর বরাদ্দকে অবশিষ্টাংশ নয়, প্রথম দাবি হিসেবে সুরক্ষিত করে, এবং কোন লাইভ সেবা সঞ্চিত পরিচালনগত ঝুঁকি বহন করছে সে বিষয়ে খোলামেলা।

  5. আমরা সুচিন্তিতভাবে কোন সামর্থ্য গড়া ও মালিক হওয়া বনাম কেনা বেছে নিচ্ছি, এবং আমরা কি না জেনেই আমাদের মূল ক্লিনিক্যাল ডেটায় লক-ইন মেনে নিচ্ছি? এখানকার শ্রেষ্ঠ চর্চা হলো সুচিন্তিতভাবে গড়া বনাম কেনা ঠিক করা, মূল ক্লিনিক্যাল ডেটায় একক-সরবরাহকারী লক-ইন এড়ানো, এবং সরবরাহকারীদের বাইরের কিছু নয়, অপারেটিং মডেলের একটি স্তর হিসেবে দেখা; এই প্রশ্ন পরীক্ষা করে সেই পছন্দগুলো আসলে করা হচ্ছে, নাকি ডিফল্টে পড়ে যাচ্ছে। এটি গুরুত্বপূর্ণ, কারণ ডিজিটাল স্বাস্থ্যে সবচেয়ে গুরুতর লক-ইন ক্লিনিক্যাল রেকর্ড ও তার ডেটা ঘিরে, যেখানে বাস্তবসম্মত প্রস্থান-পথহীন একটি মালিকানাধীন ভান্ডার পুরো একটি ব্যবস্থাকে এক দশক আটকে রাখতে পারে এবং নির্ধারণ করতে পারে পরবর্তী প্রতিটি সেবা কী করতে পারবে। টানাপোড়েন হলো গতি বনাম বিকল্প-সুযোগ: কেনা দ্রুত এবং আজ প্রায়ই সস্তা, বিশেষত একটি টানাটানির দলের জন্য, কিন্তু উন্মুক্ত মান বা প্রস্থানের অধিকারহীন প্রতিটি সুবিধাজনক কেনা নীরবে আগামীর বিকল্প সংকুচিত করে, এবং খরচ কেবল তখনই দৃশ্যমান হয় যখন আপনি ছেড়ে যেতে চেষ্টা করেন। বিষয়টি মূর্ত করুন আপনার মূল সামর্থ্যগুলো তালিকাভুক্ত করে, প্রতিটিকে কৌশলগত (গড়ুন/মালিক হোন) বা পণ্য-সামগ্রী (কিনুন) হিসেবে চিহ্নিত করে, এবং পণ্য-সামগ্রীগুলোর পেছনের চুক্তিগুলো আসলে উন্মুক্ত মান (HL7 FHIR, SNOMED CT) ও প্রয়োগযোগ্য প্রস্থানের অধিকার চায় কি না যাচাই করে। ভালো উত্তর অল্প কয়েকটি সত্যিকারের কৌশলগত সামর্থ্যকে অনেকগুলো নিরাপদে কেনা সামর্থ্য থেকে আলাদা করে, ক্লিনিক্যাল ডেটায় প্রতিষ্ঠান ইতিমধ্যে কোথায় আটকে আছে সে বিষয়ে সৎ, এবং সবচেয়ে গুরুত্বপূর্ণ চুক্তিগুলোতে উন্মুক্ত মান ও প্রস্থানের অধিকারে প্রতিশ্রুতিবদ্ধ হয়।

  6. আমাদের অপারেটিং মডেল কখন বদলানো দরকার তা আমরা কীভাবে জানব, এবং কোন সংকেত আমাদের তা বলবে, ফ্যাশনের বশে বা নতুন নেতার আগমনে পুনর্গঠনের বদলে? বিষয়টি অপারেটিং মডেলকে দেয়ালে ঝোলানো রেখাচিত্র নয়, প্রমাণের ভিত্তিতে বিবর্তিত একটি প্রোডাক্ট হিসেবে সাজায়, তাই এই প্রশ্ন দলকে আগে থেকেই সংজ্ঞায়িত করতে বলে কোন প্রমাণ এটি নতুন আকার দেওয়াকে যথার্থ করবে। স্বাস্থ্য ও পরিচর্যায় এটি গুরুত্বপূর্ণ, কারণ পুনর্গঠন বিঘ্নকারী ও ব্যয়বহুল, তা কষ্টে অর্জিত ক্ষেত্র-জ্ঞান ও ক্লিনিক্যাল-নিরাপত্তা জ্ঞান ভেঙে দেয়, তবু এই খাত নীতি-চক্র ও নতুন নিয়োগ দ্বারা চালিত কাঠামোগত ওঠানামার প্রবণ, বর্তমান মডেল আসলে বাধা হচ্ছে কি না তা দ্বারা নয়। টানাপোড়েন স্থিতিশীলতা ও অভিযোজনের মধ্যে: মডেল খুব সহজে বদলালে দলগুলো কখনো থিতু হতে বা নিরাপত্তা-দক্ষতা জমাতে পারে না, খুব কমই বদলালে জমাট বাঁধা কাঠামো কাজের সঙ্গে খাপ খাওয়া বন্ধ করার অনেক পরেও প্রবাহ রুদ্ধ করে। বিষয়টি মূর্ত করুন একটি ছোট সংকেত-সংকলন বেছে নিয়ে: কাজের প্রবাহ, সিদ্ধান্ত-নিতে-সময়, পুনঃকাজ ও দলের স্বাস্থ্য, এবং সেগুলোর কোন নড়াচড়া সুচিন্তিত পুনঃনকশা বনাম ছোট সমন্বয় ঘটাবে তা ঠিক করে। সৎ উত্তর কয়েকটি অগ্রগামী সূচকে প্রতিশ্রুতিবদ্ধ হয়, প্রমাণ-চালিত পরিবর্তনকে পুনর্গঠনের নাটক থেকে আলাদা করে, এবং সংকেত যখন বলে মডেলটি ডেলিভারি আটকাচ্ছে তখন মডেল পরীক্ষা ও পদক্ষেপ নেওয়ার জন্য কে জবাবদিহিকারী তা স্পষ্ট করে।

বাস্তবে: স্বাস্থ্য ও পরিচর্যার একটি উদাহরণ#

পাঁচটি এলাকা জুড়ে থাকা একটি ICS-এর প্রতিটি ট্রাস্ট নিজস্ব রোগী-মুখী অ্যাপয়েন্টমেন্ট টুল গড়ছে। খরচ নকল হচ্ছে, অভিজ্ঞতা ভিন্ন হচ্ছে, কেউই পরিষ্কারভাবে তথ্য ভাগ করছে না। ICS তার অপারেটিং মডেল নতুন করে নকশা করে।

এটি তিনটি ফলাফল ঠিক করে (অনুপস্থিতি কমানো, এড়ানো যায় এমন ভর্তি কাটা, প্রবেশাধিকারের ন্যায্যতা উন্নত করা) এবং তাদের পেছনের মূল্য-প্রবাহ। এটি চারটি সবচেয়ে-পাতলা-কার্যকর সামর্থ্যের মালিক একটি ছোট প্ল্যাটফর্ম দল গড়ে: একটি ভাগ করা পরিচয়/লগইন, একটি FHIR-ভিত্তিক আন্তঃকার্যক্ষমতা স্তর, নিরাপত্তা ও ক্লিনিক্যাল-নিরাপত্তা ভিত্তিসহ সাধারণ হোস্টিং এবং একটি ডিজাইন সিস্টেম। প্রতিটি এলাকা একটি স্ট্রিম-অ্যালাইনড দল রাখে, কিন্তু এখন গোড়া থেকে না গড়ে প্ল্যাটফর্মের ওপর গড়ে।

অর্থায়ন বার্ষিক প্রকল্প-দরপত্র থেকে প্রতিটি স্ট্রিমের স্থায়ী প্রোডাক্ট বাজেটে সরে যায়, যা ডিসকভারি/আলফা/বিটা গেটের মাধ্যমে ছাড় হয়। একটি প্রকাশিত RAPID মানচিত্র স্পষ্ট করে এলাকা দলগুলো প্ল্যাটফর্ম ও ক্লিনিক্যাল-নিরাপত্তা সীমারেখার মধ্যে নিজেদের সেবা-নকশা সিদ্ধান্ত নেয়, আর ICS ডিজিটাল বোর্ড প্ল্যাটফর্ম মান সিদ্ধান্ত নেয়। এক বছরের মধ্যে তিনটি এলাকা একটি বুকিং সামর্থ্য ভাগ করে, নকশা ও নিরাপত্তা ভিত্তি সামঞ্জস্যপূর্ণ, এবং যে নতুন ফিচার আগে একটি প্রকল্প-চক্র নিত তা সপ্তাহে প্রকাশিত হয়, কারণ প্ল্যাটফর্ম অভিন্ন ভারী কাজ শুষে নিয়েছে।

খাতভিত্তিক দৃষ্টিকোণ#

অপারেটিং মডেল যে প্রতিষ্ঠানকে সেবা দেয় তার আকার অনুযায়ী মাপা হয়; একই স্তরগুলো, মূল্য-প্রবাহ, সামর্থ্য, দল, গভর্ন্যান্স, প্ল্যাটফর্ম, সরবরাহকারী, একটি স্টার্ট-আপ, একটি বৃহৎ প্রতিষ্ঠান ও একটি সরকারি সংস্থা খুব ভিন্নভাবে আঁকে।

স্টার্ট-আপ#

একটি ছোট ডিজিটাল-স্বাস্থ্য কোম্পানিতে অপারেটিং মডেল বেশির ভাগই অন্তর্নিহিত, এবং সেটা ঠিকই আছে: এক-দুটি স্ট্রিম-অ্যালাইনড দল, বেশির ভাগ সিদ্ধান্তের অধিকার ধরে থাকা একজন প্রতিষ্ঠাতা, এবং কোনো প্ল্যাটফর্ম দল নেই, কারণ এখনো প্ল্যাটফর্ম করার মতো কিছু নেই। শৃঙ্খলা হলো আগেভাগে কয়েকটি প্রকৃত সিদ্ধান্ত স্পষ্ট করা, যেমন ক্লিনিক্যাল ডেটা ভান্ডারের জন্য গড়া বনাম কেনা, কোন উন্মুক্ত মানে প্রতিশ্রুতিবদ্ধ হওয়া, যাতে আজকের শর্টকাট আগামীকালের লক-ইনে পরিণত না হয়। চালানো ও পরিবর্তন একই হাতে থাকে, তাই ঝুঁকি হলো প্রাথমিক গ্রাহকদের জন্য আলো জ্বালিয়ে রাখা রোডম্যাপকে অনাহারে রাখে; প্রকৌশল-সময়ের একটি সহজ, সৎ বিভাজন সুরক্ষিত চালানোর বাজেটের হালকা সমতুল্য। সরবরাহকারী বাছাই হয় গতির জন্য, কিন্তু স্টার্ট-আপ তবু মূল-ক্লিনিক্যাল-ডেটায় লক-ইন প্রত্যাখ্যান করবে, কারণ তার ভবিষ্যৎ NHS ক্রেতারা প্রস্থানের অধিকার দাবি করবেন।

ক্ষুদ্র ব্যবসা#

একটি প্রতিষ্ঠিত ছোট প্রদানকারী, যেমন একটি জিপি প্র্যাকটিস, কমিউনিটি ফার্মেসি, কেয়ার হোম বা গৃহভিত্তিক পরিচর্যা প্রদানকারী, একক-স্থানের ক্লিনিক, বা রাজস্ব-পূর্ব পর্যায় পেরোনো একটি ছোট স্বাস্থ্য-প্রযুক্তি সরবরাহকারী, প্রকৃত রোগী ও চলমান পরিচালনা রাখে, কিন্তু প্ল্যাটফর্ম দল নেই, নিবেদিত ডিজিটাল বা IT সামর্থ্য নেই, নগদ বা কর্মীতে সামান্যই ফাঁক। এখানে অপারেটিং মডেল মূলত একসঙ্গে সেলাই করা কেনা সামর্থ্যের একটি সংকলন, তাই নির্ণায়ক পছন্দগুলো সরবরাহকারী-সংক্রান্ত: আপনি যেসব ক্লিনিক্যাল সিস্টেম কেনেন তাতে উন্মুক্ত মান ও প্রস্থানের অধিকারের জোর দিন, কারণ বড় ট্রাস্টের ক্রয়-ক্ষমতা বা ঘরোয়া দক্ষতা ছাড়াই আপনি একই আন্তঃকার্যক্ষমতা ও ক্লিনিক্যাল-নিরাপত্তা দায়িত্ব বহন করেন। চালানো ও পরিবর্তন সেই একই মুষ্টিমেয় মানুষের ওপর পড়ে যাঁরা পরিচর্যাও দেন, তাই সৎ শৃঙ্খলা হলো কেবল আগুন নেভানোর বদলে সিস্টেম নিরাপদ ও হালনাগাদ রাখতে সামান্য সময় সুরক্ষিত করা। সিদ্ধান্তের অধিকার সরল, সাধারণত একজন অংশীদার বা মালিক-ম্যানেজার সিদ্ধান্ত নেন, কিন্তু এতে ডিজিটাল সিদ্ধান্ত অনির্দিষ্টকালের জন্য স্থগিত রাখা সহজ হয়, তাই মূল্য হলো যে অল্প কয়েকটি গুরুত্বপূর্ণ (কোন ক্লিনিক্যাল রেকর্ড, কোন ভাগ করা আঞ্চলিক প্ল্যাটফর্মে যোগ দেওয়া) তার নাম বলা এবং সুচিন্তিতভাবে সেগুলো নেওয়া। যেখানে একটি ICS বা জাতীয় সংস্থা ভাগ করা পরিচয়, আন্তঃকার্যক্ষমতা বা ডিজাইন প্ল্যাটফর্ম দেয়, সেখানে ক্ষুদ্র ব্যবসার সেরা পদক্ষেপ প্রায়ই নতুন করে উদ্ভাবন না করে তার ওপর গড়া, যে সামর্থ্যে সে নিজে কর্মী জোগাতে পারে না তা ধার করা।

বৃহৎ প্রতিষ্ঠান#

একটি NHS ট্রাস্ট বা ICS হলো সেই জায়গা যেখানে প্ল্যাটফর্ম-আর-ফেডারেশন আকার তার মূল্য প্রমাণ করে: সার্বভৌম প্রতিষ্ঠান যাদের রোগীর কাছে একটি সেবার মতো মনে হতে হবে। কঠিন সমস্যাগুলো প্রযুক্তিগতের মতোই রাজনৈতিক: সময়-সীমিত প্রকল্প-দরপত্র থেকে স্থায়ী প্রোডাক্ট বাজেটে অর্থ সরানো, এবং একটি RACI/RAPID মানচিত্র প্রকাশ করা যাতে এলাকা দলগুলো যেসব সিদ্ধান্তের মালিক সেগুলো ঊর্ধ্বতনে পাঠানো বন্ধ করে। একটি বড় স্বাস্থ্য-প্রযুক্তি বা ফার্মা প্রতিষ্ঠানের প্ল্যাটফর্ম প্রকৌশলের পেশি আছে, কিন্তু ঝুঁকি আছে একটি বিশাল অভ্যন্তরীণ প্ল্যাটফর্ম অতিরিক্ত গড়ার, যা নিজেই বাধা হয়ে ওঠে; সবচেয়ে-পাতলা-কার্যকর-প্ল্যাটফর্ম পরীক্ষা, অর্থাৎ দুই বা ততোধিক দল প্রদর্শনযোগ্যভাবে একই জিনিস চায়, হলো ব্রেক। এই মাপে সিদ্ধান্তের অধিকার ও অর্থায়নের প্রবাহই অপারেটিং মডেল; প্রযুক্তি সাধারণত সীমাবদ্ধতা নয়।

সরকার#

একটি জাতীয় বা স্থানীয় সরকারি সংস্থা এমন অপারেটিং মডেল নকশা করে যাতে অন্য প্রতিষ্ঠানগুলোকে বাস করতে হয়, তাই মান ও প্ল্যাটফর্ম নিয়ে তার পছন্দ কার্যত জাতীয় অবকাঠামো। NHS England বা DHSC-র একটি ভাগ করা পরিচয় স্তর, একটি আন্তঃকার্যক্ষমতা মেরুদণ্ড বা একটি ডিজাইন সিস্টেম প্রদান হলো জনসংখ্যা-মাপে প্রয়োগ করা প্ল্যাটফর্ম ছক, এবং তার ব্যয় নিয়ন্ত্রণ ও ধাপে ধাপে আশ্বাস-গেট হলো জনগণের অর্থকে জবাবদিহিতার আওতায় রাখার উপায়। ব্যর্থতার ধরন হলো একটি কেন্দ্রীভূত মডেল যা দূরবর্তী বাধা হয়ে ওঠে, প্রতিটি স্থানীয় প্রেক্ষাপটের জন্য একটি সমাধান বাধ্যতামূলক করে; প্রতিকার হলো সত্যিকারের অভিন্ন সামর্থ্যগুলো প্ল্যাটফর্ম করা এবং বাকিগুলো ট্রাস্ট ও স্থানীয় কর্তৃপক্ষের হাতে ফেডারেট করা। পার্লামেন্টের কাছে জবাবদিহিতার অর্থ গড়া/কেনা ও সরবরাহকারী ব্যবস্থাপনাও জনগণের নথির বিষয়, তাই উন্মুক্ত মান ও প্রস্থানের অধিকার কেবল বিচক্ষণ নয়, প্রত্যাশিত।

ব্যর্থতার সাধারণ ধরন#

  • সাংগঠনিক চার্টকে স্বয়ংক্রিয় করা। মূল্য-প্রবাহের বদলে বিদ্যমান বিভাগগুলোর চারপাশে দল নকশা করা, ফলে TOM সাইলো দৃঢ় করে। প্রতিষেধক: ফলাফল ও মূল্য-প্রবাহ থেকে নিচে নকশা করুন।
  • বাধায় পরিণত হওয়া প্ল্যাটফর্ম। অতিরিক্ত-পরিধির একটি কেন্দ্রীয় প্ল্যাটফর্ম দল, যার পেছনে প্রতিটি অনুরোধকে সারিতে দাঁড়াতে হয়। প্রতিষেধক: SLA-সহ প্রোডাক্ট হিসেবে গণ্য সবচেয়ে পাতলা কার্যকর প্ল্যাটফর্ম।
  • প্রোডাক্টের কাজের জন্য প্রকল্প অর্থায়ন। যে অর্থ ফুরিয়ে যায় তা ভেঙে ফেলা-আবার গড়ার ওঠানামা বাধ্য করে। প্রতিষেধক: ধাপে ধাপে গেটসহ স্থায়ী প্রোডাক্ট অর্থায়ন।
  • পরিবর্তনকে খাওয়াতে অনাহারে রাখা চালানো। ক্লিনিক্যাল সিস্টেম ক্ষয় না হওয়া পর্যন্ত লাইভ-সেবা পরিচালনায় কম অর্থায়ন। প্রতিষেধক: চালানো ও পরিবর্তনে স্পষ্টভাবে অর্থায়ন করুন এবং চালানোর বাজেট সুরক্ষিত রাখুন।
  • মালিকহীন সিদ্ধান্ত। কেউ জানে না কে সিদ্ধান্ত নেয়, তাই সবকিছু ঊর্ধ্বতনে যায়। প্রতিষেধক: একটি প্রকাশিত RACI/RAPID।
  • ডিফল্টে লক-ইন। মূল ক্লিনিক্যাল ডেটা প্রস্থানহীন মালিকানাধীন সরবরাহকারী সিস্টেমে আটকা। প্রতিষেধক: প্রতিটি কৌশলগত চুক্তিতে উন্মুক্ত মান ও প্রস্থানের অধিকার।

পরিপক্বতা মডেল#

মাত্রা শুরু বিকাশ মানসম্মতকরণ ব্যবস্থাপনা সমন্বয়
কাঠামো সাংগঠনিক-চার্ট-চালিত, সাইলোকৃত কিছু মূল্য-প্রবাহ সারিবদ্ধতা প্ল্যাটফর্ম-আর-ফেডারেশন প্রতিষ্ঠিত সীমানা প্রবাহ-মেট্রিকের বিপরীতে শাসিত ও পর্যালোচিত ফলাফলের চারপাশে অবিরাম নতুন আকার পায়
অর্থায়ন বার্ষিক প্রকল্প মিশ্র প্রকল্প/প্রোডাক্ট ধাপে ধাপে গেটসহ প্রোডাক্ট অর্থায়ন ব্যয় ও ডেলিভারি KPI-র বিপরীতে ট্র্যাক, গেট আশ্বাসপ্রাপ্ত ফলাফল-ভিত্তিক, প্রমাণ-ছাড়া অর্থায়ন
সিদ্ধান্তের অধিকার অস্পষ্ট, সবকিছু ঊর্ধ্বতনে যায় আংশিক নথিবদ্ধ RACI/RAPID প্রকাশিত ও ব্যবহৃত সিদ্ধান্তের বিলম্ব ও ঊর্ধ্বতন-প্রেরণ পরিমাপ ও পরিচালিত স্পষ্ট সীমারেখার মধ্যে অর্পিত, কদাচিৎ ঊর্ধ্বতনে যায়
প্ল্যাটফর্ম নেই; প্রতিটি দল আবার গড়ে তাৎক্ষণিক ভাগ করা অংশ সবচেয়ে পাতলা কার্যকর প্ল্যাটফর্ম, চাহিদা-চালিত প্ল্যাটফর্ম SLA, গ্রহণ ও নির্ভরযোগ্যতা লক্ষ্যের বিপরীতে ট্র্যাক পরিপক্ব অভ্যন্তরীণ প্রোডাক্ট হিসেবে প্ল্যাটফর্ম
সরবরাহকারী লক-ইন, কৌশলগত কেনাকাটা কিছু মান আবশ্যক গড়া/কেনা সুচিন্তিতভাবে ঠিক সরবরাহকারীর কার্যকারিতা ও মান-সম্মতি আশ্বাসপ্রাপ্ত উন্মুক্ত মান, প্রস্থানের অধিকার, সুস্থ বাজার

চেকলিস্ট#

  • অপারেটিং মডেল বিদ্যমান স্তরক্রম নয়, ফলাফল ও মূল্য-প্রবাহ থেকে নকশা করা।
  • ভাগ করা সামর্থ্য সবচেয়ে-পাতলা-কার্যকর প্ল্যাটফর্ম হিসেবে দেওয়া হয়, স্ট্রিম দলগুলো তার ওপর গড়ে।
  • প্রোডাক্ট দলগুলো স্থায়ীভাবে অর্থায়িত এবং মূল্য-প্রবাহের সঙ্গে সারিবদ্ধ।
  • ব্যয় নিয়ন্ত্রণ ধাপে ধাপে (ডিসকভারি/আলফা/বিটা/লাইভ গেট) এবং ঝুঁকি ও মূল্যের আনুপাতিক।
  • সিদ্ধান্তের অধিকার নথিবদ্ধ (RACI বা RAPID) এবং প্রকাশিত।
  • চালানো ও পরিবর্তনে স্পষ্টভাবে অর্থায়ন করা হয়, চালানোর বাজেট সুরক্ষিত।
  • দলের ধরন (স্ট্রিম-অ্যালাইনড, প্ল্যাটফর্ম, এনাবলিং, জটিল-উপব্যবস্থা) বোঝা ও ব্যবহৃত।
  • গড়া/কেনা প্রতিটি সামর্থ্যের জন্য সুচিন্তিত পছন্দ; মূল ক্লিনিক্যাল ডেটা লক-ইন এড়ায়।
  • চুক্তিতে উন্মুক্ত মান (যেমন HL7 FHIR, SNOMED CT) ও প্রস্থানের অধিকার আবশ্যক।

মূল উৎস#

  • Matthew Skelton ও Manuel Pais — Team Topologies (স্ট্রিম-অ্যালাইনড, প্ল্যাটফর্ম, এনাবলিং, জটিল-উপব্যবস্থা দল; সবচেয়ে পাতলা কার্যকর প্ল্যাটফর্ম)।
  • GOV.UK Service Manual — ব্যয় নিয়ন্ত্রণ ও ধাপে ধাপে আশ্বাস (ডিসকভারি/আলফা/বিটা/লাইভ); Government Digital Service।
  • NHS ডিজিটাল সেবা ম্যানুয়াল — NHS সেবা-মান (service-manual.nhs.uk)।
  • AXELOS — পোর্টফোলিও ও প্রোগ্রাম গভর্ন্যান্সের জন্য Management of Portfolios (MoP) ও Managing Successful Programmes (MSP)।
  • Bain & Company — RAPID সিদ্ধান্ত-অধিকার কাঠামো; এবং RACI দায়িত্ব-নির্ধারণ মডেল।
  • John Doerr — ফলাফল সংজ্ঞায়নের জন্য Measure What Matters (OKR)।

তথ্যসূত্র#

  1. Operating model — Wikipedia — https://en.wikipedia.org/wiki/Operating_model
  2. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
  3. Objectives and key results (OKRs) — Wikipedia — https://en.wikipedia.org/wiki/Objectives_and_key_results
  4. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
  5. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
  6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
  7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
  8. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
  9. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais, IT Revolution — https://teamtopologies.com/book
  10. Spend controls and staged assurance (discovery/alpha/beta/live) — GOV.UK Service Manual, Government Digital Service — https://www.gov.uk/service-manual/agile-delivery
  11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
  12. Managing Successful Programmes (MSP) and Management of Portfolios (MoP) — AXELOS/PeopleCert — https://www.axelos.com/
  13. Measure What Matters (OKRs) — John Doerr — https://www.whatmatters.com/the-book

GitHub-এ এই পৃষ্ঠা সম্পাদনা করুন — বইটিই সত্যের উৎস; এই সাইট কেবল এটি উপস্থাপন করে।