یک Suite رگرسیون دستی ۸۰ نفر-ساعت زمان میبرد و اجرای خودکار آن ۴ ساعت طول میکشد. تیم ماهی دو بار Suite را اجرا میکند. Spreadsheet مینویسد: «۷۶ × ۲ × ۱۲ نفر-ساعت صرفهجویی؛ ROI مثبت؛ پروژه را تصویب کنید.» اما چهار ساعت Runtime ماشین با چهار ساعت کار انسان یکی نیست، زمان آزادشده الزاماً Cash saving نیست، Setup و نگهداری و Triage جا افتادهاند، تعداد اجرای آینده هنوز Forecast است و شاید گلوگاه Release اصلاً Regression نباشد.
ROI اتوماسیون تست (Test Automation ROI) یک درصد تزئینی برای توجیه خرید ابزار نیست. یک Automation Investment Case است که هزینهها، منافع، زمان، ریسک و گزینههای واقعی را نسبت به Baseline/Counterfactual یکسان مقایسه میکند؛ سپس Forecast را با Actuals بازبینی میکند. اگر منفعت پولی قابلدفاع ندارید، تحلیل Cost-effectiveness یا Capacity/Service case شاید صادقانهتر از ROI ساختگی باشد.
پاسخ کوتاه: برای محاسبه ROI اتوماسیون، جریان نقدی افزایشی هر گزینه را نسبت به «اگر اتوماسیون را اجرا نکنیم چه میشود؟» بسازید؛ TCO کامل، منافع Cashable/Cost avoidance/Capacity/Risk را جدا کنید؛ نرخ تنزیل و افق را ثبت کنید؛ NPV، ROI و Payback را با سناریو و حساسیت گزارش دهید؛ و هیچ Benefit را بدون Owner، Mechanism، Baseline و Evidence دوباره نشمارید.
این راهنما دقیقاً چه چیزی را مالک میشود؟
این مقاله مالک پروندهٔ تصمیم سرمایهگذاری اتوماسیون است: Decision → Options → Baseline/Counterfactual → Scope/Horizon → Cost/Benefit Registry → Cash-flow model → Risk/Uncertainty → ROI/NPV/Payback → Recommendation → Benefits realization → Correction. برای انتخاب سناریوی مناسب، هرم تست و شروع فنی به راهنمای اتوماسیون تست بروید؛ برای Evidence، Flakiness، نگهداری و Retirement هر Check، چرخهٔ عمر اتوماسیون تست مالک موضوع است.
تخصیص بودجه بین چند سرمایهگذاری QA در Portfolio بودجهبندی QA انجام میشود؛ Attribution اثر مشترک در Contribution Evaluation؛ ادعاهای اعتماد/برند در تست نرمافزار و اعتماد مشتری. این صفحه آن مالکیتها را با یک درصد ROI ادغام نمیکند.
ROI اتوماسیون تست چیست و چه نیست؟
| ROI معتبر | ROI نامعتبر |
|---|---|
| مقایسهٔ جریانهای افزایشی گزینهها با Counterfactual | جمعکردن هر منفعت QA و نسبتدادن آن به Automation |
| یک Convention نسخهدار برای هزینه/منفعت/تنزیل | فرمول بدون افق، زمان و واحد پول |
| Forecast با Range، فرض و خطای تاریخی | عدد قطعی و Break-even عمومی |
| Decision aid همراه ریسک و آثار غیرپولی | اثبات کیفیت، Cause یا تضمین بازگشت |
| Forecast→Actual→Correction | Spreadsheet یکبارمصرف برای گرفتن بودجه |
فرمول پایه و Convention
Incremental ROI over horizon H (%) =
[PV(attributable incremental benefits) - PV(incremental costs)]
────────────────────────────────────────────────────────────── × 100
PV(incremental costs)
NPV = Σ from t=0..H [incremental net cash flow_t / (1 + r)^t]
Payback = first period where cumulative net cash flow becomes non-negative
Every output must state:
perspective, option, counterfactual, horizon, currency basis,
real/nominal convention, discount rate/source, tax/accounting treatment,
cash-flow timing, uncertainty method and as-of date.
بعضی سازمانها ROI را بدون تنزیل و بعضی با Present Value گزارش میکنند. فرمول جهانی واحدی برای همهٔ Business caseها وجود ندارد؛ Convention را با Finance تصویب و کنار عدد بنویسید. NPV معمولاً زمانبندی Cash flow را بهتر از یک Ratio پنهانگر نشان میدهد. Payback نیز ارزش پس از نقطهٔ سربهسر و Risk را نادیده میگیرد؛ هیچکدام بهتنهایی تصمیم نیست.
اول Decision، نه درصد ROI
پرسش «آیا اتوماسیون ارزش دارد؟» گزینه و Authority ندارد. پرسش تصمیمی چنین است: «برای Regression مسیر Checkout در ۱۲ ماه آینده، میان O0 بهبود اجرای دستی، O1 اتوماسیون انتخابی ۲۰ سناریوی پایدار و O2 اتوماسیون گسترده، کدام گزینه با Budget و Risk appetite فعلی وارد Pilot شود؟»
investment_decision_id: AUTO-INV-SYN-042-v1 question: "کدام گزینه برای Pilot محدود Checkout انتخاب شود؟" options: [O0_MANUAL_IMPROVEMENT, O1_SELECTIVE_AUTOMATION, O2_BROAD_AUTOMATION] authority_role: ROLE-INVESTMENT-DECISION decision_due: 2026-09-15T09:00:00Z budget_ceiling: fictional IRR 900,000,000 horizon: 12 months required_outputs: [TCO, NPV, ROI, payback-range, risk, non-monetized-effects] not_deciding: [release, product-quality, people-reduction, vendor-contract] review_due: 2026-11-01T09:00:00Z
Perspective تعیین میکند چه چیزی هزینه یا منفعت است
| Perspective | چه چیزی میبیند؟ | خطر مخلوطکردن |
|---|---|---|
| Budget/Cash | پرداخت و دریافت واقعی واحد سازمانی | زمان آزادشده را Cash saving مینامد |
| Financial enterprise | اثر مالی کل سازمان و Transferهای داخلی | هزینهٔ یک واحد و منفعت واحد دیگر را دوباره میشمارد |
| Operational | Capacity، Lead time، Service level و Evidence | Outcome غیرپولی را با ROI قاطی میکند |
| Economic/social | هزینهٔ فرصت و آثار گستردهتر تحت روش رسمی | نرخ/قواعد عمومی را بیدلیل به Business case خصوصی منتقل میکند |
Perspective را Freeze کنید. Charge داخلی ممکن است برای یک تیم Cost و برای تیم دیگر Revenue باشد اما برای سازمان Transfer خنثی باشد. این مقاله Business case داخلی را توضیح میدهد، نه حسابداری رسمی، مالیات یا ارزشگذاری اجتماعی؛ Finance/Accounting مسئول باید Convention را تأیید کند.
گزینهٔ «عدم تغییر» را واقعبینانه بسازید
Counterfactual نباید «دستی برای همیشه با هزینهٔ ثابت» باشد. بدون Automation هم Scope، Release cadence، Salary، Test design، Tooling و Process تغییر میکنند. O0 میتواند بهبود Risk-based regression، حذف Case کمارزش یا Testability بهتر باشد. Automation باید با بهترین گزینهٔ جایگزین مقایسه شود، نه با وضعیت مصنوعی بد.
Baseline و Counterfactual فرق دارند
| مفهوم | تعریف | مثال |
|---|---|---|
| Baseline | مشاهدهٔ واقعی پیش از Intervention | میانهٔ effort ده Run همScope |
| Counterfactual forecast | پیشبینی اینکه بدون گزینه چه رخ میدهد | O0 با Scope و Wage forecast |
| Target | سطح مطلوب | Feedback زیر ۳۰ دقیقه |
| Actual | Outcome تحققیافته پس از تصمیم | effort و Cash outturn هر ماه |
| Variance | اختلاف Forecast و Actual با علت/Correction | Maintenance دو برابر فرض |
Baseline همScope و همکیفیت لازم است
اجرای دستی ۸۰ ساعته و اجرای خودکار چهارساعته فقط وقتی قابلمقایسهاند که Risk obligations، Scenario/Data/Environment، Oracle، Evidence و Review outcome همسطح باشند. اجرای سریعتر که فقط ۲۰٪ Scope را پوشش میدهد Benefit همان Suite نیست. Eligible population و Acceptance of evidence را نسخهدار کنید.
Scope و Horizon را قبل از Cost model ثابت کنید
«اتوماسیون Regression» بیش از حد بزرگ است. Subject، Product/Service، Journey، Test level، Browser/device/environment، Scenario population، Data، CI cadence، Start/ramp/steady/retirement dates و Out-of-scope را بنویسید. Horizon کوتاه هزینهٔ Setup را برجسته و Horizon دور Benefits نامطمئن را بزرگ میکند؛ هر دو باید با Decision و عمر محتمل Artifact متناسب باشند.
از Options analysis استفاده کنید
| گزینه | توصیف | Trade-off |
|---|---|---|
| O0 | بهبود اجرای دستی، Sampling و Testability | Setup کم؛ تکرار انسانی بیشتر |
| O1 | ۲۰ سناریوی پایدار/پرتکرار با Evidence محدود | قابلبازگشتتر؛ Benefit محدود اما آزمونپذیر |
| O2 | Suite گسترده چندمرورگر/داده | Coverage بالقوه بیشتر؛ TCO، Flake و Lock-in بالاتر |
| O3 | خرید سرویس/پلتفرم مدیریتشده | Time-to-start کمتر؛ Vendor/FX/exit risk |
گزینهها باید Scope/Outcome مشترک داشته باشند و Reversibility/stop/exit روشن باشد. پروژهٔ بزرگ نامطمئن را میتوان با Real option ساده به Pilot مرحلهای شکست: مبلغ کوچک برای خرید Evidence، سپس Gate برای Scale/Redesign/Stop؛ نه Commitment کامل براساس Forecast اولیه.
TCO اتوماسیون تست چیست؟
Total Cost of Ownership فقط License و نوشتن Script نیست. تمام منابع افزایشی لازم برای طراحی، ساخت، اجرا، تفسیر، نگهداری، کنترل و خروج را در Horizon میگیرد. برای هر Cost، Quantity×Unit cost، timing، source، owner، range، escalation و double-count check ثبت کنید.
| Cost family | نمونهها | محرک |
|---|---|---|
| Discovery/design | Risk mapping، feasibility، architecture، pilot | سناریو و Integration |
| Build | Framework، Check، Data factory، Oracle، CI integration | Complexity/coverage obligation |
| Tool/infrastructure | License، Runner، Cloud compute، device، storage | Concurrency/execution/minutes |
| Operation | Trigger، monitoring، result review، evidence retention | Run frequency/failure volume |
| Maintenance | Product/locator/data/env change، dependency upgrade | Change rate/coupling |
| Failure demand | Flake triage، rerun، false alert، outage، quarantine | Signal quality |
| Enablement/governance | Training، review، security، privacy، audit، accessibility | team/control scope |
| Transition/exit | Migration، decommission، export، vendor lock-in | architecture/vendor |
| Opportunity cost | بهترین کار جایگزین تیم | capacity diverted |
هزینهٔ نیروی انسانی را دو بار نشمارید
اگر Full-loaded hourly rate شامل Salary، Benefits و Overhead است، آنها را دوباره اضافه نکنید. Calendar time و person-hours جدا هستند. چهار مهندس × دو هفته الزاماً ۸ نفر-هفتهٔ Incremental cash نیست اگر Salary ثابت میماند؛ اما Capacity/opportunity cost دارد. Finance باید Cash، accounting allocation و economic opportunity را تفکیک کند.
Runtime ماشین با Effort انسان فرق دارد
| زمان | واحد/Cost | در مدل |
|---|---|---|
| Wall-clock runtime | دقیقه تا Feedback | Service outcome و compute |
| Compute minutes | Runner×minute | Infrastructure cash/capacity |
| Human setup effort | person-hour | Operational cost |
| Review/triage effort | person-hour | Failure demand |
| Waiting blocked time | person-hour یا queue-hour | فقط با Evidence و overlap rule |
| Elapsed release lead time | calendar duration | Outcome؛ خودکار Cash benefit نیست |
Maintenance را Driver-based برآورد کنید
درصد ثابت «مثلاً ۲۰٪ ساخت» برای همهٔ Suiteها قابلدفاع نیست. Drivers را ثبت کنید: Product change rate، UI/API coupling، Test-data churn، Environment instability، Dependency/tool upgrades، Flake، skill mix و retirement. Range را از Pilot و Historical analogues بسازید و Actual maintenance را جدا از feature expansion نگه دارید.
Failure demand هزینهٔ پنهان اصلی است
Failed Check یک Defect نیست. Triage، rerun، quarantine، investigation، environment recovery و alert fatigue منابع مصرف میکنند. Cost model باید Accepted signal، false alert، product failure، test defect، environment failure و unknown را جدا کند. Suite پرسرعت با Signal ضعیف ممکن است TCO را بیشتر کند.
Sunk cost در تصمیم آینده
Green Book ۲۰۲۶ دولت بریتانیا میگوید هزینهٔ غیرقابلبازگشتِ رخداده نباید تصمیم آینده را منحرف کند، اما Opportunity cost منابع موجود مهم است. برای تصمیم Continue/Stop، هزینهٔ سال قبل Sunk است؛ نگهداری آینده، ارزش جایگزین Runner و Exit cost Incrementalاند. این راهنمای Appraisal دولتی، قالب اجباری شرکت یا نرخ تنزیل ایران نیست.
Cost Estimate باید Audit trail داشته باشد
راهنمای Cost Estimating سازمان GAO آمریکا بر purpose/scope/schedule، Technical baseline، Work breakdown، assumptions، data، method، sensitivity/risk، documentation و بهروزرسانی با Actual costs تأکید میکند. این منبع عمدتاً برنامههای بزرگ را هدف دارد؛ ما فقط اصول Auditability را متناسب و محدود اقتباس میکنیم.
cost_item_id: COST-AUTO-042-17 option_id: O1_SELECTIVE_AUTOMATION work_package: failure-demand/triage quantity: 18..42 person-hours/month unit_cost: fictional IRR/person-hour; finance-approved source timing: months 2..12 method: three-point estimate from shadow pilot assumptions: [run-frequency-v2, failure-mix-v1] dependencies: [runner-stability, product-change-rate] owner_role: ROLE-COST-OWNER source_refs: [PILOT-SYN-042, RATE-CARD-SYN-v3] double_count_group: HUMAN_OPS actuals_source: TIMESHEET-AGGREGATE-v2 confidence_basis: limited synthetic pilot; low not_claimed: market rate or future certainty
Benefit taxonomy: همهٔ منفعتها پول نقد نیستند
| نوع Benefit | تعریف | ورود به Cash ROI |
|---|---|---|
| Cashable saving | کاهش واقعی پرداخت/بودجه با Action مشخص | بله، پس از Finance validation |
| Cost avoidance | هزینهٔ آیندهٔ محتمل که واقعاً اجتناب میشود | با Counterfactual و probability؛ جدا از Cash saving |
| Released capacity | نفر-ساعت آزاد برای کار دیگر | خودکار نه؛ ابتدا Capacity |
| Throughput/service | Feedback/Lead time/frequency/availability بهتر | فقط با Mechanism مالی جدا |
| Risk reduction | کاهش Exposure یا probability/consequence | Expected value با شواهد و عدمقطعیت |
| Non-monetized outcome | Evidence، accessibility، learning، experience | جدا در Scorecard؛ نه پول ساختگی |
زمان آزادشده چه زمانی Cash saving است؟
کاهش ۱۰۰ person-hour با Salary ثابت، پرداخت سازمان را ۱۰۰ ساعت کم نمیکند. Cashable میشود اگر Overtime/Vendor spend حذف، استخدام برنامهریزیشده واقعاً اجتناب، Contract کاهش یا بودجه آزاد و ثبت شود. در غیر این صورت Released capacity است؛ Benefit مهمی که باید Owner و redeployment plan داشته باشد.
capacity_benefit_id: BEN-CAP-042 baseline_effort: comparable accepted manual evidence/person-hours future_counterfactual_effort: range by run and month automated_human_effort: setup + review + triage + maintenance released_capacity: counterfactual - automated effort redeployment_action: "risk-based exploratory sessions for uncovered paths" owner_role: ROLE-CAPACITY-OWNER cashable: false cash_conversion_trigger: none approved double_count_rule: do not also book as salary saving or new revenue evidence_due: monthly actuals
صرفهجویی اجرای دستی را درست محاسبه کنید
فرمول خام (manual time − automation runtime) × runs × hourly rate سه خطا دارد: Runtime ماشین را effort انسان میگیرد، همهٔ Runهای Forecast را قطعی میداند و Scope/quality را همسان فرض میکند. مدل بهتر، Manual human effort را با Automation setup/review/triage/maintenance human effort مقایسه و Compute/License را جدا میکند؛ فقط Runهای واجدشرایط و احتمال تحقق را میگیرد.
Frequency Benefit را باد نکنید
اگر Suite خودکار روزی ۲۰ بار اجرا شود، نمیتوان ادعا کرد ۲۰ اجرای دستی کامل «صرفهجویی» شده؛ تیم احتمالاً هرگز ۲۰ Run دستی انجام نمیداد. Counterfactual واقعبینانه را مدل کنید. Runهای افزوده میتوانند Evidence/feedback Benefit باشند، نه avoided manual cash.
Cost avoidance با Savings فرق دارد
«در آینده پنج نفر لازم داشتیم، حالا نداریم» Forecast هزینهٔ اجتنابشده است، نه Cash outturn. Hiring plan، trigger، probability، timing، wage basis و جایگزینها را ثبت کنید. وقتی برنامهٔ استخدام هرگز تصویب نشده، اجتناب آن Benefit قطعی نیست.
ادعای «رفع باگ در Production صد برابر گرانتر است» را حذف کنید
Multiplier جهانی ۱۰۰× بدون Dataset، Defect class، Phase، Cost boundary و روش قابلانتقال نیست. هزینهٔ یک Typo، Data corruption و Security incident یکسان نیست. از دادهٔ داخلی Incident/Defect cohort با Work breakdown استفاده کنید و Range بدهید. اگر داده ندارید، Benefit را Hypothesis یا Scenario نگه دارید، نه درآمد قطعی.
Expected avoided loss چگونه مدل میشود؟
Expected incremental avoided loss =
Σ scenarios [
(P_loss_without_option - P_loss_with_option)
× consequence_if_loss
× eligible_exposure
]
Required boundaries:
- scenario and asset/journey
- probability method and uncertainty
- consequence components and caps
- automation detection/control mechanism
- existing controls and overlap
- attribution/contribution assumption
- no double count with defect-cost or revenue benefit
- specialist and decision-authority review
این فرمول Cause را ثابت نمیکند. Probability delta باید از Pilot، Historical comparison، Experiment یا expert elicitation شفاف بیاید و Scenario analysis آن را stress-test کند. Catastrophic hypothetical را با احتمال ۱ و خسارت دلخواه ضرب نکنید. Risk acceptance و Release همچنان تصمیمهای جدا هستند.
Time-to-market فقط با مسیر درآمدی Benefit مالی است
کوتاهشدن Runtime تضمین نمیکند Release جلو بیفتد؛ Bottleneck شاید Product approval، Deployment یا Compliance باشد. حتی Release زودتر نیز خودکار Revenue نمیسازد. Critical path، release-date delta، eligible demand، incremental margin، cannibalization، adoption و سایر Constraints لازماند. در نبود آنها، Lead time یک Operational outcome است.
Coverage و تعداد Script Benefit مالی نیستند
Script count، Execution count و Code coverage Activity/Output هستند. Benefit باید به Decision/Outcome متصل شود و Guardrail داشته باشد. هزار Check کمارزش ممکن است Triage را زیاد کند. Risk-evidence obligations accepted، actionable feedback و avoided rework کاندیدهای دقیقتریاند؛ باز هم Attribution جدا میخواهند.
اعتماد، رضایت، روحیه و برند را پولسازی نکنید
Automation→باگ کمتر→رضایت/وفاداری/برند→درآمد یک زنجیرهٔ بلند با عوامل مشترک است. بدون Theory، Measure، Baseline، valuation method و Attribution، آن را Non-monetized hypothesis نگه دارید. ادعای اعتماد باید طبق مرزهای شواهد اعتماد مشتری بررسی شود؛ «روحیه بهتر» نیز نیازمند سنجش داوطلبانه و حریم خصوصی است.
Double counting را با Benefit Registry بگیرید
| ادعاهای همپوشان | خطر | قاعده |
|---|---|---|
| زمان آزادشده + Salary saving | یک effort دو Benefit | Capacity یا Cash؛ فقط با conversion ثبتشده |
| Defect avoided + Incident avoided | یک Scenario دوبار | Canonical scenario/benefit group |
| Lead time + Revenue earlier | Operational outcome و مالی تکراری | فقط Revenue delta در Cash، Lead time در Scorecard |
| Coverage + Quality + Trust | Output به سه Outcome تبدیل میشود | Coverage non-monetized؛ Outcome مستقل |
| Hiring avoided + Vendor avoided | دو Alternative برای یک Demand | Counterfactual option-specific |
benefit_id: BEN-AUTO-042-08 option_id: O1_SELECTIVE_AUTOMATION type: RELEASED_CAPACITY subject_outcome: accepted comparable regression evidence baseline_ref: BASE-SYN-042 counterfactual_ref: CF-O0-v2 mechanism: stable checks replace named repeatable manual steps measure_contract: M-CAPACITY-v3 quantity_range: 70..110 person-hours/month monetization: NONE owner_role: ROLE-BENEFIT-OWNER evidence_refs: [RUN-REGISTRY-v2, EFFORT-SNAPSHOT-v3] dependencies: [run-volume, scope-equivalence, signal-quality] double_count_group: REGRESSION_CAPACITY not_claimed: cash-saving, revenue, quality, people-reduction realization_due: monthly
Nominal، Real و Inflation را مخلوط نکنید
Cash flowهای Nominal شامل Inflation forecastاند و باید با نرخ Nominal سازگار Discount شوند؛ Real cash flowها با قیمت ثابت و نرخ Real. نرخ تورم را دوباره به Discount rate اضافه نکنید. Salary، Cloud، License و FX ممکن است Escalation متفاوت داشته باشند. Finance باید Source/as-of/scenario را تأیید کند.
ریال، تومان و نرخ ارز در پروندهٔ ایرانی
واحد Canonical را IRR یا واحد رسمی موردتوافق Finance نگه دارید؛ تومان فقط View صریحاً برچسبدار باشد. مبلغ «۵۰ میلیون» بدون واحد ممنوع است. هزینهٔ License ارزی باید Currency، quantity، FX source، as-of، settlement assumptions، fees و low/base/high scenario داشته باشد. این مقاله توصیهٔ ارزی، تحریمی، مالیاتی، حقوقی یا حسابداری نیست.
money_contract: MONEY-SYN-v2 canonical_currency: fictional IRR display_toman: presentation-only; explicitly labelled; divide by 10 price_basis: nominal base_date: 2026-08-01 foreign_item_currency: fictional USD fx_source: FINANCE-APPROVED-SYN-v1 fx_as_of: 2026-08-01T09:00:00Z fx_scenarios: [LOW, BASE, HIGH] fees_and_tax: finance review required; not assumed zero rounding: store integer IRR; round only presentation legal_sanctions_accounting_claim: none
Discount rate را از اینترنت قرض نگیرید
Green Book برای ارزیابی اجتماعی دولت بریتانیا نرخهای خاص خودش را دارد؛ استفاده از آن برای Cash flow تجاری ایران بیدلیل است. Finance باید نرخ و Convention متناسب با Perspective، Currency، inflation basis و Risk treatment را تصویب کند. Risk را هم در Cash-flow scenario و هم در Discount rate دوبار اعمال نکنید.
NPV، ROI، Payback و Break-even چه میگویند؟
| Measure | مزیت | محدودیت |
|---|---|---|
| NPV | زمان و اندازهٔ Net cash flow را میبیند | به نرخ/Forecast حساس است؛ non-cash outcome را پنهان میکند |
| ROI | Ratio قابلفهم در Convention ثابت | Scale و timing را پنهان و با تعریفهای مختلف تغییر میکند |
| Payback | زمان بازیابی را نشان میدهد | پس از Payback و value/risk را نادیده میگیرد |
| Break-even runs | برای یک Scenario ساده مفید است | Runها و maintenance را ثابت فرض میکند |
| Cost-effectiveness | هزینه به ازای Outcome غیرپولی | ارزش مالی خالص نمیدهد |
Break-even اجراها را فقط برای مدل محدود استفاده کنید
If and only if scope/evidence are equivalent and per-run values are stable: Break-even runs ≈ incremental setup cost ───────────────────────────────────────────────── manual human cost/run - automated variable cost/run Automated variable cost/run must include: human setup + review + triage + expected maintenance allocation + compute/device/license variable cost If denominator ≤ 0: no finite break-even under this model. Report a range, not a universal 9–18 month promise.
چرا Break-even عمومی ۹ تا ۱۸ ماه معتبر نیست؟
Setup، Run frequency، Manual effort، Change rate، Flake، Tool/FX و عمر Suite متفاوتاند. بعضی Checkها در چند Run و بعضی هرگز Break-even نمیشوند؛ بعضی برای Risk evidence ساخته میشوند نه صرفهجویی. فقط Distribution محلی و Scenario-specific گزارش دهید و شرط Invalidation را بنویسید.
عدمقطعیت را از ورودی تا خروجی حفظ کنید
یک Point estimate حس دقت کاذب میدهد. برای Setup، maintenance، run volume، accepted-signal rate، capacity conversion، FX و discount rate مقدار Low/Base/High یا Distribution مستند بسازید. Range باید از Data یا expert method بیاید، نه ±۲۰٪ دلخواه.
Optimism bias را با خطای Forecast تاریخی تنظیم کنید
Green Book ۲۰۲۶ Optimism bias را تمایل نظاممند به کمبرآوردکردن Cost/Duration و بیشبرآوردکردن Benefit میداند و توصیه میکند Adjustment از خطاهای تاریخی طرحهای مشابه بیاید. برای Automation، Forecast-versus-actual Setup، maintenance، adoption و Benefit را نگه دارید. درصد دولتی/صنعتی را بدون تناسب کپی نکنید.
Sensitivity analysis و Switching value
بپرسید NPV به کدام فرض حساس است: Run volume؟ Maintenance؟ Cash conversion؟ FX؟ Switching value نشان میدهد متغیر تا چه سطحی تغییر کند که Recommendation عوض شود. اگر فقط با Forecast خوشبینانه O1 برنده است، Decision brief باید Fragility را آشکار کند.
| Driver | Low | Base | High | Invalidate when |
|---|---|---|---|---|
| Runهای واجدشرایط/ماه | ۲ | ۶ | ۱۰ | Scope equivalence شکست بخورد |
| Maintenance h/month | ۱۸ | ۳۰ | ۴۲ | Product architecture تغییر کند |
| Accepted-signal rate | ساختگی ۰٫۵۵ | ۰٫۷۵ | ۰٫۹۰ | Oracle/Environment عوض شود |
| Capacity cash conversion | ۰٪ | ۰٪ | فقط با Action مصوب | Budget action لغو شود |
| FX index | FIN-LOW | FIN-BASE | FIN-HIGH | Source/as-of منقضی شود |
همهٔ اعداد جدول ساختگی و صرفاً برای نشاندادن Structure هستند؛ نرخ بازار، Benchmarks اتوماسیون یا Forecast واقعی ایران نیستند.
Scenario analysis بهجای یک آیندهٔ قطعی
| Scenario | فرضهای سازگار | خروجی مجاز |
|---|---|---|
| Low | Run کم، maintenance/FX بالا، conversion صفر | NPV/ROI/Payback range |
| Base | Pilot median و Finance base | مرکز Forecast، نه «محتمل قطعی» |
| High | Run بالا، maintenance پایین، signal خوب | Upside مشروط |
| Stress | Vendor exit، architecture change، Suite retirement | Downside/stop/contingency |
Monte Carlo همیشه لازم نیست
برای Pilot کمهزینه، Low/Base/High و Sensitivity شفاف ممکن است کافی باشد. شبیهسازی پیچیده با Distributionهای حدسی فقط دقت کاذب میسازد. روش باید متناسب با Cost، Risk، Reversibility و کیفیت داده باشد و Reproducible code/seed/assumptions داشته باشد.
Attribution: Automation تنها تغییر سیستم نیست
همزمان ممکن است Requirement، Architecture، Observability، Team، Release cadence و Traffic تغییر کنند. کاهش Defect یا Lead time را کامل به Automation نسبت ندهید. Theory of Change، contribution evidence، alternatives و Countermetric لازماند؛ روش جامع در Contribution Evaluation QA آمده است.
Pilot برای خرید Evidence، نه اثبات قبلی
Pilot باید Unknownهای Decision را هدف بگیرد: Setup effort، Run eligibility، maintenance drivers، signal quality، triage burden، Scope equivalence و adoption. Exit criteria را پیش از اجرا بنویسید. اگر Pilot فقط بهترین Scenario را انتخاب کند، Selection bias تولید میکند. برای Intervention test از Experiment در بهبود مستمر QA استفاده کنید.
Benefits realization بعد از تصویب آغاز میشود
Business case Forecast است؛ Benefit فقط با Action و Evidence محقق میشود. Magenta Book دولت بریتانیا از جمله میپرسد Cost/Benefit واقعی چگونه با Appraisal/Business case مقایسه شد. این راهنمای Evaluation سیاست عمومی، استاندارد Automation نیست؛ اصل قابلانتقال آن Forecast→Actual→Learning است.
benefit_realization_record: BR-AUTO-042-M03 benefit_ref: BEN-AUTO-042-08 forecast_range: 70..110 person-hours released actual: 46 person-hours released measurement_contract: M-CAPACITY-v3 counterfactual_version: CF-O0-v2 variance: below range drivers: [fewer-eligible-runs, higher-triage] cash_realized: fictional IRR 0 operational_action: redesign flake/data isolation owner_role: ROLE-BENEFIT-OWNER decision_impact: continue-shadow; do-not-scale correction_ref: COR-AUTO-042-03
Forecast accuracy یک Countermetric است
اگر Business caseها همیشه Benefits بالا و Cost پایین پیشبینی میکنند، Portfolio یاد نمیگیرد. Error/Bias را برای Setup، Run volume، maintenance، cash conversion، NPV و Payback نگه دارید؛ نه برای تنبیه افراد، بلکه برای Calibration روش. تغییر فرض پس از مشاهده باید نسخه و rationale داشته باشد.
Stage Gate و Stop rule
| Gate | Evidence | گزینهها |
|---|---|---|
| G0 Explore | Decision/Options/Baseline/Data readiness | Reject/Design Pilot |
| G1 Pilot | Setup/TCO/signal/Scope equivalence | Stop/Redesign/Extend |
| G2 Limited active | Forecast range و operating controls | Limit/Scale conditionally |
| G3 Realization | Actual cost/benefit/variance | Continue/Correct/Retire |
| G4 Exit | Residual obligations/data/vendor/knowledge | Archive/Migrate/Decommission |
Stop شکست نیست؛ جلوگیری از هزینهٔ بیشتر با Evidence تازه است. Scale نباید فقط چون Setup قبلاً خرج شده رخ دهد. Sunk-cost fallacy را با Decisionهای افزایشی و گزینهٔ Retirement مهار کنید.
Recommendation باید مشروط و قابلانقضا باشد
recommendation_id: REC-AUTO-042-v1 recommend: O1_SELECTIVE_AUTOMATION / SHADOW_PILOT_ONLY basis: [TCO-v2, BENEFIT-REG-v2, SCENARIO-v1, PILOT-DESIGN-v3] conditions: [scope-equivalence, data-fitness, finance-convention-approved] unknowns: [maintenance-tail, eligible-run-volume, capacity-realization] confidence_basis: low; pre-pilot estimates stop_triggers: [signal-acceptance<0.55, maintenance>42h/month, data-breach] scale_triggers: [two mature review periods, base-NPV non-negative, controls-pass] authority_role: ROLE-INVESTMENT-DECISION expires_at: 2026-11-01T09:00:00Z not_claimed: ROI guaranteed, quality, revenue, release, headcount reduction
گزارش مدیریتی بدون پنهانکردن عدمقطعیت
Decision brief باید گزینهها، Incremental TCO، Benefit classification، NPV/ROI/Payback range، top sensitivities، non-monetized outcomes، Unknowns، Reversibility، Stop/Scale و Authority را در یک صفحه نشان دهد و Technical trace داشته باشد. برای قرارداد Claim/Option/Decision از Quality Decision Brief استفاده کنید.
Dashboard ROI چه ستونهایی دارد؟
- Investment-case ID/revision/as-of/expiry و Decision/Authority
- Option و Counterfactual version، Scope و Horizon
- Cost/Benefit Registry با Cash/Capacity/Risk/Non-monetized labels
- Nominal/Real/Currency/FX/Discount Convention
- Low/Base/High/Stress: NPV، ROI و Payback
- Top sensitivities، switching values و assumptions
- Forecast/Actual/Variance و Benefits owner/action
- Data fitness، Attribution limits و double-count flags
- Stop/Scale triggers، status و Correction history
نقشها و اختیارها
| نقش قابلیتمحور | مسئولیت | اختیار پیشفرض ندارد |
|---|---|---|
| Investment sponsor | Objective، option، resource و Benefit ownership | تغییر Evidence مالی |
| Automation owner | Scope، technical baseline، TCO drivers | تأیید مستقل ROI خودش |
| Benefit owner | Action، realization، Actual/variance | Claim بدون Measure |
| Finance reviewer | Currency، rate، Cash/Capacity، tax/accounting convention | تصمیم فنی Test coverage |
| Independent analyst | Counterfactual، double count، sensitivity، reproducibility | Investment authority |
| Decision authority | Approve/Limit/Stop/Scale و Risk trade-off | بازنویسی Dataset |
| Security/privacy owner | Vendor/data/access/retention controls | Benefit monetization |
AI و ابزارهای ROI چه مرزی دارند؟
- Spreadsheet/code میتواند Cash flow، NPV، ROI، Payback، scenario و double-count rules را Reproducible اجرا کند.
- Pipeline باید Currency/basis/time/unit mismatch و Missing owner/source را HOLD کند.
- AI میتواند Cost/Benefit candidate و Sensitivity question پیشنهاد کند؛ مبلغ، probability، Cause یا Market data را اختراع نکند.
- LLM نباید Trust/brand/defect loss را بدون Evidence Monetize یا Investment decision صادر کند.
- هر مدل/ابزار باید Version، formula، inputs، rounding، test cases، access و human review داشته باشد.
امنیت، Vendor و داده
Tool trial ممکن است Test data، Source، Screenshots، Logs، Tokens و Usage telemetry را خارج کند. Data classification، residency، DPA/contract، access، secrets، retention/deletion، export، incident، subcontractor، model-training opt-out، sanctions/export constraints و exit plan را با مسئولان مربوط بررسی کنید. هزینهٔ Controls و Exit بخشی از TCO است؛ این مقاله مشاورهٔ حقوقی، امنیتی یا تحریمی نیست.
Correction و Supersession
correction_id: COR-AUTO-042-03 corrects: AUTO-INV-SYN-042-v1 / SCENARIO-v1 reason: manual effort counted machine runtime as human effort affected_inputs: [BEN-CAP-042, COST-RUN-042] old_claim: base ROI positive new_claim: ROI under review; capacity only, cash conversion zero affected_decisions: [DEC-AUTO-042] issued_at: 2026-10-01T09:00:00Z superseding_artifacts: [AUTO-INV-SYN-042-v2, SCENARIO-v2] owner_role: ROLE-INVESTMENT-ANALYST silent_edit: false
آزمایش اجرایی: ROI مثبت روی Spreadsheet ناقص
Fixture زیر کاملاً ساختگی، آفلاین و غیرقابلتعمیم است. Checker سطحی، ۸۰ ساعت دستی منهای ۴ ساعت Runtime را دو بار در ماه ضرب و با Setup مقایسه میکند و `APPROVE_AUTOMATION` میگوید. ممیزی قرارداد ۶۴ Rule دارد؛ Rule آخر People-reduction را منع میکند و چون false است، نسخهٔ خام دقیقاً ۶۳ Finding میگیرد. این تعداد Benchmark بلوغ یا صنعت نیست.
const draft = {
manual_hours_per_run: 80,
automation_runtime_hours: 4,
runs_per_month: 2,
horizon_months: 12,
hourly_rate_fictional_irr: 5_000_000,
setup_cost_fictional_irr: 600_000_000,
declared_status: "APPROVE_AUTOMATION",
people_reduction: false
};
const present = (v) =>
v !== undefined && v !== null &&
!(typeof v === "string" && v.trim() === "") &&
!(Array.isArray(v) && v.length === 0);
const rules = [
["ROI-01 case_id", x => present(x.case_id)],
["ROI-02 revision", x => present(x.revision)],
["ROI-03 supersedes", x => present(x.supersedes)],
["ROI-04 as_of", x => present(x.as_of)],
["ROI-05 decision_question", x => present(x.decision_question)],
["ROI-06 options", x => present(x.options)],
["ROI-07 authority", x => present(x.authority)],
["ROI-08 decision_due", x => present(x.decision_due)],
["ROI-09 perspective", x => present(x.perspective)],
["ROI-10 scope", x => present(x.scope)],
["ROI-11 out_of_scope", x => present(x.out_of_scope)],
["ROI-12 horizon", x => present(x.horizon)],
["ROI-13 baseline_ref", x => present(x.baseline_ref)],
["ROI-14 counterfactual_ref", x => present(x.counterfactual_ref)],
["ROI-15 scope_equivalence", x => present(x.scope_equivalence)],
["ROI-16 evidence_equivalence", x => present(x.evidence_equivalence)],
["ROI-17 cost_registry", x => present(x.cost_registry)],
["ROI-18 technical_baseline", x => present(x.technical_baseline)],
["ROI-19 work_breakdown", x => present(x.work_breakdown)],
["ROI-20 setup_cost", x => present(x.setup_cost)],
["ROI-21 build_cost", x => present(x.build_cost)],
["ROI-22 tool_license_cost", x => present(x.tool_license_cost)],
["ROI-23 infrastructure_cost", x => present(x.infrastructure_cost)],
["ROI-24 human_operation_cost", x => present(x.human_operation_cost)],
["ROI-25 compute_runtime_cost", x => present(x.compute_runtime_cost)],
["ROI-26 maintenance_cost", x => present(x.maintenance_cost)],
["ROI-27 triage_failure_demand", x => present(x.triage_failure_demand)],
["ROI-28 training_governance", x => present(x.training_governance)],
["ROI-29 transition_exit_cost", x => present(x.transition_exit_cost)],
["ROI-30 opportunity_cost", x => present(x.opportunity_cost)],
["ROI-31 benefit_registry", x => present(x.benefit_registry)],
["ROI-32 benefit_types", x => present(x.benefit_types)],
["ROI-33 benefit_owners", x => present(x.benefit_owners)],
["ROI-34 benefit_mechanisms", x => present(x.benefit_mechanisms)],
["ROI-35 benefit_measures", x => present(x.benefit_measures)],
["ROI-36 capacity_redeployment", x => present(x.capacity_redeployment)],
["ROI-37 cash_conversion_rule", x => present(x.cash_conversion_rule)],
["ROI-38 cost_avoidance_rule", x => present(x.cost_avoidance_rule)],
["ROI-39 risk_benefit_method", x => present(x.risk_benefit_method)],
["ROI-40 non_monetized_outcomes", x => present(x.non_monetized_outcomes)],
["ROI-41 double_count_groups", x => present(x.double_count_groups)],
["ROI-42 attribution_limits", x => present(x.attribution_limits)],
["ROI-43 money_contract", x => present(x.money_contract)],
["ROI-44 currency", x => present(x.currency)],
["ROI-45 real_nominal_basis", x => present(x.real_nominal_basis)],
["ROI-46 inflation_assumptions", x => present(x.inflation_assumptions)],
["ROI-47 fx_assumptions", x => present(x.fx_assumptions)],
["ROI-48 discount_rate", x => present(x.discount_rate)],
["ROI-49 discount_rate_source", x => present(x.discount_rate_source)],
["ROI-50 tax_accounting_review", x => present(x.tax_accounting_review)],
["ROI-51 cash_flow_timing", x => present(x.cash_flow_timing)],
["ROI-52 roi_convention", x => present(x.roi_convention)],
["ROI-53 npv", x => present(x.npv)],
["ROI-54 roi", x => present(x.roi)],
["ROI-55 payback_range", x => present(x.payback_range)],
["ROI-56 scenarios", x => present(x.scenarios)],
["ROI-57 sensitivity", x => present(x.sensitivity)],
["ROI-58 optimism_bias", x => present(x.optimism_bias)],
["ROI-59 assumptions_invalidation", x => present(x.assumptions_invalidation)],
["ROI-60 realization_plan", x => present(x.realization_plan)],
["ROI-61 stop_scale_rules", x => present(x.stop_scale_rules)],
["ROI-62 not_claimed", x => present(x.not_claimed)],
["ROI-63 correction_policy", x => present(x.correction_policy)],
["ROI-64 people_reduction_prohibited", x => x.people_reduction !== true]
];
const naiveSaved =
(draft.manual_hours_per_run - draft.automation_runtime_hours) *
draft.runs_per_month * draft.horizon_months * draft.hourly_rate_fictional_irr;
const naiveRoi =
((naiveSaved - draft.setup_cost_fictional_irr) / draft.setup_cost_fictional_irr) * 100;
const findings = (x) => rules.filter(([, ok]) => !ok(x)).map(([id]) => id);
console.log("SUPERFICIAL", draft.declared_status, Math.round(naiveRoi) + "%");
console.log("CONTRACT", findings(draft).length ? "HOLD" : "READY", findings(draft).length);
const corrected = {
case_id: "SYN-AUTO-INV-042", revision: "v1", supersedes: "none:first-revision",
as_of: "2026-08-01T09:00:00Z", decision_question: "which option enters shadow pilot",
options: ["O0_MANUAL_IMPROVEMENT", "O1_SELECTIVE_AUTOMATION", "O2_BROAD_AUTOMATION"],
authority: "ROLE-INVESTMENT-DECISION", decision_due: "2026-09-15T09:00:00Z",
perspective: "internal incremental cash plus separate capacity scorecard",
scope: "20 fictional stable Checkout regression scenarios", out_of_scope: ["release", "production", "people"],
horizon: "12 months", baseline_ref: "BASE-SYN-042", counterfactual_ref: "CF-O0-v2",
scope_equivalence: "same risk obligations/population", evidence_equivalence: "same accepted evidence profile",
cost_registry: "COST-REG-v2", technical_baseline: "TECH-SYN-C42", work_breakdown: "WBS-AUTO-v2",
setup_cost: "three-point estimate", build_cost: "framework+checks+data+oracle",
tool_license_cost: "finance quote scenario", infrastructure_cost: "runner/device/storage",
human_operation_cost: "setup+review", compute_runtime_cost: "runner-minutes",
maintenance_cost: "change-driver range", triage_failure_demand: "failure-mix range",
training_governance: "enablement+security+review", transition_exit_cost: "migration+decommission",
opportunity_cost: "best alternative capacity use", benefit_registry: "BEN-REG-v2",
benefit_types: ["CASHABLE", "COST_AVOIDANCE", "CAPACITY", "RISK", "NON_MONETIZED"],
benefit_owners: ["ROLE-CAPACITY-OWNER", "ROLE-FINANCE-OWNER"],
benefit_mechanisms: "versioned per benefit", benefit_measures: "versioned per benefit",
capacity_redeployment: "risk-based exploratory sessions", cash_conversion_rule: "zero unless approved action",
cost_avoidance_rule: "approved counterfactual+probability", risk_benefit_method: "scenario expected-value range",
non_monetized_outcomes: ["feedback-time", "evidence-repeatability"],
double_count_groups: ["REGRESSION_CAPACITY", "DEFECT_RISK"],
attribution_limits: ["architecture", "testability", "release-process"],
money_contract: "MONEY-SYN-v2", currency: "fictional IRR",
real_nominal_basis: "nominal", inflation_assumptions: "FIN-INF-SYN-v1",
fx_assumptions: "FIN-FX-SYN-v1 low/base/high", discount_rate: "finance-approved fictional nominal rate",
discount_rate_source: "FIN-RATE-SYN-v1", tax_accounting_review: "required; not assumed",
cash_flow_timing: "monthly end-of-period", roi_convention: "PV benefits minus PV costs / PV costs",
npv: "range by scenario; fictional", roi: "range by scenario; fictional",
payback_range: "no universal point; scenario range", scenarios: ["LOW", "BASE", "HIGH", "STRESS"],
sensitivity: ["run-volume", "maintenance", "cash-conversion", "fx"],
optimism_bias: "calibrate from historical forecast error", assumptions_invalidation: "ASSUME-REG-v2",
realization_plan: "monthly forecast-to-actual with owners", stop_scale_rules: "GATE-AUTO-v2",
not_claimed: ["guaranteed-ROI", "quality", "revenue", "brand", "release", "headcount-reduction"],
correction_policy: "supersede; no silent edit", people_reduction: false
};
const correctedFindings = findings(corrected);
console.log("CORRECTED", correctedFindings.length ? "HOLD" : "READY_FOR_INVESTMENT_REVIEW", correctedFindings.length);خروجی مستقل Fixture و تفسیر
SUPERFICIAL APPROVE_AUTOMATION 1420% CONTRACT HOLD 63 CORRECTED READY_FOR_INVESTMENT_REVIEW 0
Spreadsheet خام ۱۴۲۰٪ میسازد چون تمام فاصلهٔ Manual hours و Machine runtime را Cash saving، همهٔ Runها را قطعی و Setup را تنها Cost میگیرد. ۶۳ فیلد ساختاری ندارد؛ Rule منع People reduction تنها Rule پاسشده است. نسخهٔ اصلاحشده صفر Finding ساختاری دارد اما صحت Cost/Benefit، اعتبار Counterfactual، کفایت Pilot، مناسببودن نرخ، NPV مثبت، ROI واقعی، Payback، کیفیت، درآمد، Risk یا درستی تصمیم را ثابت نمیکند. نام خروجی عمداً `READY_FOR_INVESTMENT_REVIEW` است.
آزمایشگاه آفلاین Checkout ایرانی
Lab کاملاً جدا از Production بسازید: Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger، Reconciliation و اعلان ساختگی. سناریوهای timeout پیش/پس از Fake commit، retry، duplicate/late/out-of-order callback، Collector outage، Flake و Runner failure را اجرا کنید. Manual و Automated path باید Risk obligation، Data، Oracle و Evidence یکسان داشته باشند.
lab_id: SYN-IR-CHECKOUT-AUTO-ROI-01
network: disabled
production_data: forbidden
identities: [Option, Cost, Benefit, Run, Build, Evidence, Snapshot, Decision]
canonical_currency: fictional IRR
toman_view: presentation-only and explicitly labelled
foreign_currency: fictional scenario only; no market rate
digits: [Persian, Arabic, Latin]
unicode_pairs: [ی/ي, ک/ك]
event_time: ISO-8601 UTC
display_timezone: Asia/Tehran
jalali_date: presentation-only
forbidden: [real company, vendor quote, market FX, user, order, payment, PSP,
bank, PAN, CVV2, OTP, account, mobile, email, IP, cookie, token,
credential, production log, screenshot]
claims: synthetic, non-representative, no financial/legal/tax/security advice
تمام مبالغ، نرخها و ۱۴۲۰٪ Fixture ساختگیاند. IRR را Canonical و تومان را View برچسبدار نگه دارید؛ FX واقعی وارد Lab نکنید. UTC زمان Canonical، Asia/Tehran نمایش و جلالی فقط Presentation است. هیچ شرکت، Vendor، بازار، حقوق، Salary، نرخ ارز یا زمان Break-even واقعی ایران از Lab نتیجه نمیشود.
Pilot سیروزهٔ Investment Case
- روز ۱ تا ۵: Decision، Options، Perspective، Scope/Horizon و Baseline/Counterfactual را Review کنید.
- روز ۶ تا ۱۰: Technical baseline/WBS، Cost/Benefit/Money contract و Double-count groups را Freeze کنید.
- روز ۱۱ تا ۲۰: Shadow automation را روی Scenarioهای همScope اجرا و Setup/Run/Triage/Maintenance/Signal Actuals را بگیرید.
- روز ۲۱ تا ۲۵: Low/Base/High/Stress، NPV/ROI/Payback، Sensitivity و Switching values را Recompute کنید.
- روز ۲۶ تا ۳۰: Independent/Finance/Security review؛ سپس REJECT، REDESIGN، EXTEND_PILOT یا LIMITED_ACTIVE را ثبت کنید.
سی روز وعدهٔ Break-even نیست؛ فقط دورهٔ جمعآوری Evidence اولیه است. اگر Maintenance tail یا Benefit maturity طولانیتر است، تصمیم Scale را به تعویق بیندازید. Unknown و Stop خروجیهای سالماند.
ضدالگوهای ROI اتوماسیون تست
- مقایسهٔ Manual person-hours با Machine runtime
- تبدیل تمام Capacity آزادشده به Salary/Cash saving
- فرض اینکه هر اجرای خودکار جای یک Run دستی کامل را گرفته
- حذف Triage، Flake، Maintenance، Governance و Exit از TCO
- Counterfactual مصنوعی بدون بهبود دستی یا تغییر Scope
- Scope/Oracle/Evidence نامساوی میان گزینهها
- Multiplier بیمنبع ۱۰۰× برای Defect cost
- Automation→Time-to-market→Revenue بدون Critical path
- Coverage/Script count بهعنوان Benefit پولی
- Monetize کردن Trust، brand، morale و satisfaction بدون روش
- Double count زمان، Defect، Incident و Revenue
- مخلوطکردن Real/Nominal و IRR/toman/FX
- قرضگرفتن نرخ تنزیل خارجی بدون Finance convention
- ROI نقطهای بدون Range/Sensitivity/Invalidation
- Break-even عمومی ۹ تا ۱۸ ماه
- Scale بهخاطر Sunk cost
- Business case بدون Benefit owner و realization action
- Silent edit Forecast پس از دیدن Actuals
- استفاده از ROI برای حذف/رتبهبندی افراد
- اعلام ROI مثبت بهعنوان کیفیت یا Release readiness
چکلیست Owner پیش از ارائه Business Case
- Decision، Options، Authority، Due و not-deciding ثبتاند.
- Perspective، Scope، Out-of-scope و Horizon ثابتاند.
- Baseline مشاهدهشده و Counterfactual آینده جدا هستند.
- Scope/Oracle/Evidence بین گزینهها همارز است.
- Technical baseline و WBS نسخه دارند.
- Setup/Build/Tool/Infra/Operation/Maintenance/Triage کاملاند.
- Training/Governance/Security/Transition/Exit/Opportunity cost آمدهاند.
- Quantity×Unit cost×Timing×Source×Owner برای هر Cost وجود دارد.
- Cash saving، avoidance، capacity، risk و non-monetized جدا هستند.
- Capacity فقط با Action مصوب Cash میشود.
- Benefit mechanism/measure/owner/evidence/realization due ثبتاند.
- Double-count groups و Attribution limits مرور شدهاند.
- Money contract، IRR/toman، Real/Nominal، Inflation/FX سازگارند.
- Discount/tax/accounting Convention توسط Finance بررسی شده است.
- Cash-flow timing و ROI convention کنار خروجی دیده میشوند.
- NPV/ROI/Payback با Low/Base/High/Stress گزارش شدهاند.
- Sensitivity، switching value، optimism bias و invalidation روشناند.
- Stop/Scale/Expiry و Reversibility تعریف شدهاند.
- Forecast→Actual→Variance→Correction owner دارد.
- هیچ Guarantee، ۱۰۰×، ۹–۱۸ ماه یا people-reduction claim باقی نمانده است.
پرسشهای متداول درباره ROI اتوماسیون تست
فرمول ROI اتوماسیون تست چیست؟
یک Convention رایج برابر است با (PV منافع افزایشی قابلانتساب − PV هزینههای افزایشی) ÷ PV هزینهها × ۱۰۰. اما Perspective، Counterfactual، Horizon، Currency، Real/Nominal، Discount rate، Cash timing و Tax/accounting treatment باید کنار عدد ثبت شوند. NPV و Payback range را نیز نشان دهید.
آیا زمان آزادشدهٔ تستر مستقیماً صرفهجویی مالی است؟
خیر. با Salary ثابت، معمولاً Released capacity است. فقط وقتی پرداخت واقعی مانند Overtime/Vendor/Contract کم یا استخدام مصوب واقعاً اجتناب شود و Finance آن را تأیید کند Cashable/Cost avoidance میشود. همان زمان را دوباره بهعنوان Salary saving و Revenue نشمارید.
اتوماسیون تست چه زمانی به نقطه سربهسر میرسد؟
عدد عمومی ۹ تا ۱۸ ماه وجود ندارد. Setup، Run volume، Scope equivalence، human review/triage، maintenance، Tool/compute/FX و عمر Suite تعیینکنندهاند. Payback را برای Low/Base/High گزارش کنید؛ اگر منفعت متغیر هر Run از هزینهٔ متغیر بیشتر نیست، مدل ساده Break-even محدود ندارد.
آیا کاهش باگ یا Time-to-market را میتوان Benefit مالی گرفت؟
فقط با Scenario/Mechanism، Counterfactual، probability/attribution، Cost boundary و Evidence. «۱۰۰× هزینهٔ باگ» یا Automation→Revenue قابلقبول نیست. در نبود داده، کاهش Defect/Lead time را Operational یا Risk hypothesis نگه دارید و با Benefit پولی جمع نکنید.
اگر ROI منفی شد باید اتوماسیون را متوقف کنیم؟
نه خودکار. Data/Convention، گزینهها، non-monetized obligations، Risk، Reversibility و Switching values را بررسی کنید. ممکن است Cost-effectiveness یا Compliance/Evidence need توجیه محدود داشته باشد؛ یا Stop بهترین تصمیم باشد. Authority باید Incremental future costs/benefits را ببیند، نه Sunk cost را.
جمعبندی: ROI را اندازهگیری نکنید؛ پروندهٔ تصمیم را بسازید
ROI اتوماسیون تست از کمکردن چهار ساعت Runtime از ۸۰ ساعت Manual بهدست نمیآید. گزینه و Counterfactual واقعی، Scope/Evidence همسان، TCO کامل، Benefit taxonomy، Money convention، Cash-flow timing، عدمقطعیت و Attribution لازماند. Cash، Capacity، Service و Risk را در یک سبد بینام مخلوط نکنید.
Business case را Forecast نسخهدار بدانید. با Pilot Unknownها را کم کنید، NPV/ROI/Payback range و Sensitivity را شفاف ارائه دهید، Benefit owner و Stop rule بگذارید و Actuals را به فرضها برگردانید. تحلیل خوب Automation را از پیش «سرمایهگذاری هوشمند» اعلام نمیکند؛ به تصمیمگیر نشان میدهد تحت کدام شرایط، با چه Evidence و چه Downside محدود، کدام گزینه ارزش آزمودن دارد.
