10.615 min read

Enterprise MACD Operations

MACD — Move, Add, Change, Disconnect — describes the four fundamental lifecycle operations performed on active services. While MACD exists in consumer BSS too (upgrading a broadband plan, adding a TV package), enterprise MACD is a fundamentally different challenge. Enterprise MACD operates at scale (hundreds or thousands of sites), involves contractual and financial implications, requires multi-level approval chains, and must be coordinated across complex service hierarchies.

In consumer BSS, a single customer might perform 2-3 MACD operations per year. An enterprise customer with 500 sites, 5,000 users, and a portfolio of connectivity, voice, and cloud services might generate hundreds of MACD operations per month. The BSS must handle this volume efficiently while maintaining contractual integrity, SLA continuity, and billing accuracy.

Enterprise MACD vs Consumer MACD

Enterprise vs Consumer MACD

Dimension	Consumer MACD	Enterprise MACD
Scale	Single service instance, single site	Hundreds of service instances across multiple sites, often in a single change request
Approval	Instant (self-service) or agent-approved	Multi-level approval chain: requester → line manager → IT director → procurement → finance
Contract Impact	Minimal — standard T&Cs apply	Every change must be assessed for contract impact: does it alter committed spend, SLA scope, or pricing tier?
Billing Impact	Simple pro-rata adjustment	Complex: may trigger volume tier recalculation, committed spend adjustment, or contract amendment
Change Window	Immediate or next available slot	Scheduled maintenance windows; business-critical services may only be changed outside business hours
Rollback	Undo the change (usually trivial)	Rollback plan required before execution; some changes are irreversible (e.g., site decommission)
Testing	Not typically required	Pre-change testing and post-change verification often mandated by the customer's change management process
Documentation	Minimal (order confirmation email)	Formal change records, impact assessments, approval audit trails, and updated service documentation

MACD (Move, Add, Change, Disconnect)

The four fundamental lifecycle operations that can be performed on an active, in-service product or service instance. In TM Forum terms, MACD operations are expressed through Product Order Items (TMF622) with specific action types: Move is modelled as a coordinated delete + add, Add uses the add action, Change uses the modify action, and Disconnect uses the delete action. Enterprise MACD is distinguished from consumer MACD by its scale, approval requirements, contract implications, and scheduling constraints.

Beginner

MACD Volume in Enterprise Accounts

A single large enterprise account can generate more MACD activity per month than thousands of consumer accounts combined.

Consider a multinational bank with 800 branch offices, 50,000 user seats, and a portfolio spanning WAN connectivity, UCaaS, managed security, and cloud interconnect. In any given month: 5-10 branches may relocate or close; 200-500 user seats may be added, moved, or removed due to hiring, attrition, and reorganisation; 20-30 bandwidth changes may be requested as usage patterns evolve; and seasonal demand may require temporary capacity increases. This generates 250-550 individual MACD operations per month from a single customer. The BSS must process these efficiently while maintaining full contract and billing integrity.

MACD Operations in Detail

Move Operations

A Move operation relocates a service from one location to another. In enterprise BSS, this is not simply changing an address field — it involves decommissioning services at the old site and provisioning equivalent services at the new site, often on different underlying network infrastructure.

Site relocation: An enterprise moves a branch office from one building to another. All connectivity, voice, and managed LAN services must be re-established at the new location.
Technology migration: Services at a site are moved from one access technology to another (e.g., legacy leased line to Ethernet). The customer-facing service (CFS) may remain the same while the underlying resource service (RFS) changes entirely.
Platform migration: Services are moved between operator platforms during a transformation programme. Product specifications, catalog entries, and billing may all change.
Make-before-break: The preferred approach where the new service is established and tested before the old service is disconnected. Requires temporary dual provisioning, which has cost and capacity implications.
Contract continuity: A Move must preserve the existing contract terms, SLA commitments, and pricing — unless the move itself triggers a contract amendment (e.g., the new site is in a different country with different rate cards).

Move Is the Most Complex MACD

Move operations are effectively a coordinated Add + Disconnect with continuity requirements. They touch every layer of the stack — catalog (is the same offering available at the new location?), order management (coordinated cease/provide), fulfillment (new site survey, civil works, installation), billing (pro-rata adjustments, new site charges), and SLA management (service credits during transition). Many operators track Move separately from other MACD types due to its complexity.

Delta Ordering with Contract Impact Analysis

Intermediate

Delta Ordering with Contract Impact Analysis

Delta ordering processes only the differences between the current state and the desired state of a service, while simultaneously evaluating the commercial impact of those changes against the active contract.

In enterprise MACD, every change request must be evaluated on two axes: the technical delta (what needs to change in the service and resource layers) and the commercial delta (how does this change affect the contract, pricing, and billing). A bandwidth upgrade, for example, has a technical delta (increase port speed, update QoS profile) and a commercial delta (higher monthly recurring charge, possible tier change, possible volume discount recalculation). The BSS must calculate both deltas, present the combined impact for approval, and only then initiate fulfillment. This dual-delta approach is fundamental to enterprise order management and significantly more complex than consumer change orders where the pricing impact is usually a simple plan price difference.

Contract Impact Analysis in Practice

A well-implemented enterprise BSS presents the full impact of a proposed MACD before execution: "This change will add 3 sites and upgrade bandwidth at 12 sites. Monthly recurring charge increases from $42,000 to $51,500. You will move into Tier 3 volume pricing, reducing your per-site rate by 5%. Net impact: +$7,200/month. Your committed minimum spend of $40,000/month remains satisfied. No contract amendment required." This level of pre-change visibility is what enterprise customers and their procurement teams expect.

Bulk MACD: 500-Site Bandwidth Upgrade

Real-World Scenario: 500-Site Bandwidth Upgrade

A national retailer with 500 store locations requests a bandwidth upgrade from 50Mbps to 200Mbps at all sites to support a new cloud-based point-of-sale system. The upgrade must be completed within 60 days, cannot disrupt trading hours (changes only between 22:00-06:00), and must maintain Gold SLA throughout. The contract amendment increases the annual contract value by $1.8M. This single MACD request generates 500 individual service orders, each requiring scheduling coordination, change window management, and post-change verification.

Bulk MACD Execution Flow

Bulk Request Submission

Enterprise Portal / COM

Enterprise submits a bulk change request via the enterprise portal or API. The request specifies the target sites (all 500 or a CSV upload of site IDs), the desired change (bandwidth from 50Mbps to 200Mbps), and constraints (change window: 22:00-06:00, completion deadline: 60 days). COM validates the request against the partner catalog and contract entitlements.

Feasibility & Impact Assessment

COM / SOM / ROM / Pricing Engine

COM queries SOM/ROM to assess technical feasibility at each site: can the existing access infrastructure support 200Mbps? Sites are classified: "auto-upgradable" (software change only, ~420 sites), "requires CPE swap" (~60 sites), and "requires access upgrade" (~20 sites). Pricing engine calculates the aggregate contract impact.

Approval Chain

Approval Workflow / Enterprise Portal

The impact assessment is presented for approval: total cost increase, per-site breakdown, sites requiring physical intervention, projected completion timeline. The enterprise customer's authorised approver signs off. The operator's internal pricing authority approves the contract amendment for the $1.8M increase.

Order Decomposition & Scheduling

COM / SOM / Scheduler

COM decomposes the bulk order into 500 individual service orders. SOM groups them into execution waves based on site category: Wave 1 (auto-upgradable, weeks 1-4), Wave 2 (CPE swap, weeks 3-6), Wave 3 (access upgrade, weeks 4-8). Each order is assigned a change window slot within the 22:00-06:00 constraint.

Wave Execution

SOM / ROM / Activation / Field Force

Orders are executed in waves. Auto-upgradable sites are handled remotely by the activation platform. CPE swap sites require field engineer dispatch. Access upgrade sites require carrier coordination. Progress is tracked on a real-time dashboard visible to both the operator and the enterprise customer.

Post-Change Verification

Assurance / Test Platform

Each completed site undergoes automated service testing: bandwidth measurement, latency check, packet loss verification, and SLA compliance confirmation. Failed verifications trigger automatic rollback and reschedule. The enterprise customer receives per-site completion notifications.

Billing Activation & Contract Update

Billing / Contract Management

As each site is verified, billing is updated to reflect the new bandwidth charge effective from the completion date. The contract amendment is formally recorded. A final reconciliation report is generated showing all 500 sites, their completion dates, and the aggregate billing impact.

Approval Chains and Change Windows

Enterprise MACD operations are governed by formal approval chains and change windows — concepts that barely exist in consumer BSS. An enterprise customer's IT organisation typically has strict change management processes (often ITIL-aligned) that the operator's BSS must integrate with or respect.

Internal approval chain: The enterprise customer has its own approval hierarchy — a branch manager can approve a minor configuration change, but a bandwidth upgrade requires IT director sign-off, and a contract amendment requires procurement approval
Operator approval chain: High-value changes, custom SLA modifications, or non-standard pricing require internal operator approvals — pricing authority, technical review, and commercial sign-off
Dual approval: Both the customer and operator must approve before execution. The BSS must track both approval states and only proceed when both are obtained
Delegated authority: Some enterprise customers delegate MACD authority to specific individuals or roles via the enterprise portal, with spending limits and scope restrictions
Change Advisory Board (CAB): Major changes may require CAB review — a formal meeting where the proposed change, its risks, and its rollback plan are evaluated before approval is granted

Change Window Violations

Executing a change outside the agreed change window is a serious operational failure. If an operator modifies an enterprise customer's production WAN during business hours without authorisation, and the change causes a service disruption, the operator may be liable for SLA penalties and consequential damages. The BSS must enforce change window constraints at the scheduling level — preventing orders from being dispatched for execution outside approved windows. Emergency changes require explicit out-of-window approval.

MACD Approval Authority Matrix

Change Type	Enterprise Approver	Operator Approver	Typical Lead Time
Administrative change (contact update)	Any authorised user	Auto-approved	Immediate
Minor configuration change	Site or IT manager	Auto-approved	1-2 business days
Bandwidth upgrade/downgrade	IT director	Service delivery manager	5-10 business days
New site addition	IT director + Procurement	Commercial manager + Technical lead	2-6 weeks
Contract amendment (scope change)	CIO / VP Procurement	Pricing authority + Legal	2-4 weeks
Full disconnect / contract termination	C-level / VP Procurement	Account director + Finance	30-90 days notice

Enterprise MACD Lifecycle

Request

Enterprise Portal / CRM

The MACD request is submitted via the enterprise portal, partner API, or through the account management team. The request captures the desired change, affected services/sites, preferred schedule, and business justification. An initial classification determines the MACD type (M/A/C/D) and complexity level.

Impact Analysis

COM / SOM / Pricing Engine

The BSS performs a comprehensive impact analysis covering: technical feasibility (can the change be made?), service dependency analysis (what else is affected?), SLA impact (will SLA continuity be maintained?), and commercial impact (how does this change the billing, contract, and volume commitments?). The analysis is compiled into an impact report.

Approval

Approval Workflow Engine

The impact report is routed through the applicable approval chain. Enterprise customer approval is obtained first (confirming they accept the impact). Operator internal approvals follow if required (pricing authority, technical review). Both approval timestamps and approver identities are recorded for audit.

Schedule

Scheduler / Workforce Management

The approved MACD is scheduled for execution within the agreed change window. For bulk operations, scheduling includes wave planning and resource allocation (field engineers, remote activation slots). Appointment booking with the enterprise customer may be required for on-site work. Calendar confirmations are sent to all parties.

Execute

SOM / ROM / Activation

The MACD is executed according to the plan. This may involve remote network configuration, CPE reprovisioning, field engineer dispatch, or a combination. Execution progress is tracked in real time. If execution encounters an issue, the predefined rollback procedure is initiated. The enterprise customer is notified of progress at agreed milestones.

Verify

Assurance / Test Platform

Post-execution verification confirms the change was successful. Automated tests check service availability, performance parameters, and SLA compliance. For configuration changes, the new configuration is compared against the intended target state. Manual verification may be required for complex changes. The enterprise customer is invited to perform their own acceptance testing.

Close

COM / Billing / Inventory

Once verification is complete and the enterprise customer confirms acceptance, the MACD is closed. Service Inventory and Product Inventory are updated to reflect the new state. Billing is adjusted effective from the change completion date. The change record is archived with full audit trail: request, impact analysis, approvals, execution logs, and verification results.

Understanding Enterprise MACD at Different Levels

MACD stands for Move, Add, Change, Disconnect — the four things you can do with an active service. Think of it like managing a phone plan: you can move it to a new address (Move), add a new feature like international calling (Add), change your data allowance (Change), or cancel the service (Disconnect).

In enterprise (business) telecoms, MACD is more complex because businesses have many services across many locations. Imagine a company with 200 offices — if they want to upgrade their internet speed, that is 200 individual change operations that need to be coordinated, approved, and executed without disrupting business operations.

Every MACD operation starts with a request and ends with a verified change
Enterprise MACD requires approvals — you cannot just make changes without permission
Changes can only happen during agreed "change windows" to avoid disrupting business
The BSS must track every MACD operation for billing accuracy and audit purposes

At the intermediate level, MACD operations are understood as delta orders processed through the standard COM-SOM-ROM pipeline with additional enterprise-specific gates: contract impact analysis, multi-party approval, change window scheduling, and post-change verification.

The critical concept is dual-delta processing. When an enterprise submits a change request, the BSS calculates two deltas simultaneously:

Technical delta: What needs to change in the service and resource layers? COM reads the current product instance from Product Inventory (TMF637), compares it to the desired state, and generates the minimal set of order items with modify, add, or delete actions.
Commercial delta: What is the financial impact? The pricing engine evaluates the change against the contract terms — monthly recurring charge difference, one-time charges, volume tier impact, committed spend impact, and any early change fees.
Combined impact presentation: Both deltas are combined into an impact report that is presented for approval before any fulfillment activity begins.

TMF622 Order Item Actions for MACD

TMF622 uses the action field on Product Order Items to express MACD operations: add (Add new service or component), modify (Change an existing service parameter), delete (Disconnect/remove a service), and noChange (include for context but do not action). A Move operation is typically modelled as a combination of delete at the old location and add at the new location, linked by an orderItemRelationship to indicate they are part of a coordinated move.

At the advanced level, enterprise MACD introduces orchestration challenges that push the limits of standard BSS/OSS architectures. Bulk MACD operations (affecting hundreds of services simultaneously) require specialised handling:

Wave-based execution: Bulk changes are divided into execution waves to manage risk and resource constraints. Wave 1 might cover "easy" sites (remote configuration only), Wave 2 covers sites requiring CPE intervention, and Wave 3 covers sites requiring infrastructure changes. Wave progression gates prevent advancing if failure rates exceed a threshold.
Idempotent activation: When executing hundreds of changes, some will fail and need to be retried. The activation layer must be idempotent — resubmitting a change order for a site that was partially activated must complete the change without duplicating work or causing configuration conflicts.
Correlation and compensation: In bulk MACD, individual site failures must not block the entire operation. The orchestrator must track the state of each site independently, correlate completion events back to the parent bulk order, and execute compensation (rollback) only for failed sites while allowing successful sites to proceed.
Contract-aware scheduling: The scheduler must consider contract-level constraints — for example, a contract might specify that no more than 10% of sites can be in a "changing" state simultaneously, to limit the blast radius of a failed change.
Billing alignment: Bulk changes that complete over multiple weeks create complex billing scenarios. Sites upgraded in Week 1 start paying the new rate immediately, while sites upgraded in Week 4 continue at the old rate. The billing system must handle per-site effective dates within a single contract amendment.

MACD Automation Maturity

The maturity of enterprise MACD automation is a key differentiator for BSS platforms. Level 1: manual order creation per site. Level 2: bulk order submission with manual scheduling. Level 3: automated feasibility assessment and wave planning. Level 4: fully automated zero-touch MACD for eligible change types (e.g., bandwidth changes on software-defined infrastructure). Most operators today operate at Level 2-3, with Level 4 achievable only for specific, well-defined change types on modern, API-driven network infrastructure.

Section 10.6 Key Takeaways

Enterprise MACD (Move, Add, Change, Disconnect) is fundamentally different from consumer MACD — it operates at scale, involves contractual implications, requires formal approvals, and must respect change windows
Move is the most complex MACD type — effectively a coordinated Add + Disconnect with service continuity requirements
Delta ordering processes only the difference between current and desired state, reducing fulfillment complexity and minimising service disruption
Every enterprise MACD must be evaluated on two axes: the technical delta (what changes in the network) and the commercial delta (what changes in the contract and billing)
Bulk MACD operations (affecting hundreds of sites) require wave-based execution, per-site state tracking, and contract-aware scheduling
Approval chains and change windows are enforced constraints in enterprise MACD — executing changes without proper approval or outside agreed windows is an operational failure with financial consequences
The enterprise MACD lifecycle follows seven stages: Request, Impact Analysis, Approval, Schedule, Execute, Verify, Close — each with specific system responsibilities
MACD automation maturity (from manual per-site orders to zero-touch automated changes) is a key BSS capability differentiator for enterprise customers