Section I · The Brief
The developer problem
The client, a global discrete-manufacturing group operating sixty-eight plants across fourteen countries, ran an SAP ECC estate with a developer-user population of 4,200 across the ABAP, BW, FI/CO, and SolMan technical teams. The renewal forecast for the developer-tier licences alone was four point nine million dollars, a thirty-eight percent increase over the prior contract value driven by the size growth of the developer population over the contract term.
The classification methodology in use assigned every user with a developer authorisation object to the Developer tier — a methodology that captured the full population but did not reflect actual use. Internal IT had repeatedly flagged that the methodology over-stated the count, but procurement had been unable to mobilise a reclassification programme inside the fifteen months between contract anniversaries.
The brief was specific: rebuild the developer-user classification on activity evidence over a twelve-month window, identify which users genuinely required the Developer tier on the SAP licence-band definitions, and present a defensible reclassification to procurement before the renewal proposal deadline.
Section II · The Opening Claim
The existing count
The opening position was inherited from the SAP-supplied LAW output. The LAW report assigned all 4,200 users to the Developer tier and presented this as the contracted commitment for the upcoming renewal.
The breakdown by authorisation pattern was as follows.
- 1,800 users with SE38/SE80 ABAP development authorisations — ostensibly the core development population.
- 1,200 users with SQVI/SQ01 query-builder authorisations classified as developer on the role-collection basis.
- 600 users with SolMan ChaRM authorisations classified as developer for transport-management activity.
- 400 users with BW data-modelling authorisations classified as developer on the BW developer-licence definition.
- 200 users with basis-administration authorisations classified as developer on the technical-administration interpretation.
Section III · The Defence
The reclassification programme
We took the engagement on a renewal-preparation footing with no SAP audit in flight. The evidence brief was a TCODE-history extract over twelve months for the full 4,200-user population, supplemented by ChaRM transport-history extracts for the SolMan population and BW query-history extracts for the BW population.
The analysis tested every user against the SAP-published Developer-tier definition, which requires the user to have used a development transaction for the creation, modification, or activation of ABAP code, BW data models, or Java application objects. The methodology distinguished between authorisation-to-develop and activity-as-developer — the first is a security-design choice, the second is a licensing-relevant fact.
The reclassification recommendations broke down as follows: 1,400 users moved from Developer to Professional on the ABAP side where the user had read-only TCODE history; 900 users moved from Developer to Limited Professional where the activity was confined to query-builder use; 500 SolMan ChaRM users moved to a Professional tier on the basis that ChaRM transport approval is not a development activity under the contracted definition; 300 BW users moved to Professional on the basis that BW report-running is not modelling; 100 basis users remained at Developer on the basis that basis administration falls within the Developer-tier definition.
The output was a developer-user population of 1,000 against the prior 4,200, with the remaining 3,200 users moved to Professional, Limited Professional, or Employee Self-Service tiers as appropriate. The reclassification evidence file documented the transaction-history basis for every move, with a per-user evidence sheet that survived subsequent SAP review.
- TCODE-history extract over a 12-month evidence window for all 4,200 users
- ChaRM transport-history extract for the 600-user SolMan population
- BW query-history extract for the 400-user BW population
- Per-user evidence sheet for each of the 3,200 reclassifications
- Reclassification rolled into the SAP estate over three release windows
Section IV · The Settlement
The renewal outcome
The developer-tier renewal forecast was revised from four point nine million dollars to one point five million dollars — a sixty-nine percent reduction. The contracted developer-tier commitment was renewed at the lower level with a 200-user headroom buffer for organic growth over the contract term.
The contract language was updated to reference the activity-based classification methodology as the agreed measurement standard for future USMM runs, removing the interpretation risk on the Developer-tier definition. The reclassification evidence file was deposited as a contractual annex.
Total elapsed time from engagement to completed reclassification was fourteen weeks. The renewal closed within the original contract floor on the corrected developer-tier baseline.
Section V · Lessons Applicable
What others can use
Five takeaways from the matter that apply to any organisation managing a large developer-user population.
- Authorisation is not activity. The Developer-tier definition references the use of a development transaction for object creation, modification, or activation — not the possession of a developer authorisation object.
- Query-builder authorisations are not development authorisations under the contracted definition. SQVI and SQ01 use is a Professional or Limited-Professional activity, not a Developer-tier activity.
- ChaRM transport approval is not a development activity. SolMan users whose only ChaRM activity is approval routing should not be on the Developer tier.
- Run the TCODE-history extract over a twelve-month window, not a three-month window. Quarterly cycles miss the long-tail developer who works in monthly or quarterly bursts.
- Deposit the methodology in a contractual annex. The reclassification only sticks across renewals if the measurement standard is contractually agreed.
