Oracle Siebel is licensed based on:
- User Licenses: Categorized into different types according to access and functionalities.
- Named User Plus (NUP) Licenses: These are assigned to specific individuals (employees, business partners, contractors).
- Application User Licenses: This is for users needing access to specific Siebel applications.
- Processor Licenses: Based on the number of processors running Siebel software.
- Enterprise Licenses: Comprehensive access to multiple Oracle products, including Siebel.
- Siebel CRM Base Application: Each Siebel customer must license at least one Siebel CRM Base Application. Industry-specific functionality requires additional industry-based options.
Overview of Siebel CRM Modules and Industry Verticals
Oracle Siebel CRM is a modular platform encompassing various functional areas and industry-specific solutions.
Key modules include:
- Siebel Sales: Sales force automation for managing accounts, contacts, opportunities, and quotes and forecasting.
- Siebel Service ( Customer service and contact center management for handling support cases, helpdesk tickets, and customer inquiries.
- Siebel Marketing: Campaign management and marketing resource management to plan and track marketing initiatives.
- Siebel Field Service: Field technician dispatch and service order management for on-site service operations.
- Siebel Loyalty: Loyalty program and rewards management for customer retention programs.
- Siebel Partnip Management (PRM): Partner and reseller management via partner portals, enabling collaboration with external business partners.
- Siebel Analytics: Reporting and business intelligence (originally Siebel’s analytics module, now largely part of Oracle Business Intelligence) for dashboards and data analysis Tools:** Configuration and development environment for customizing Siebel application developers/administrators).
Siebel also offers industry-specific verticals—pre-built solutions tailored to sectors such as Financial Services, Telecommunications (Communications, Media, and energy), the Public Sector, Life Sciences, and more.
These versions often require a special industry-based module (for example, Siebel Financial Services or Siebel Communications). They may also have vertical-specific modules (e.g., Siebel CME Contracts instead of generic Contract】.
In practice, any Siebel deployment will include one or more of the above modules in the core Siebel CRM Base to fit the business’s needs. It’s important to note that all these modules are technically accessible in the software—Siebel does not enforce license keys for each module by default. Unlicensed modules could be activated unless governance is in place: Each Siebel module is generally licensed separately (typically per user).
For example, if you deploy Siebel Sales and Siebel Service, you must purchase licenses for each module’s users. That said, industry-specific versions often replace the generic modules (you would license Siebel Financial Services Sales instead of standard Sales, for instance).
Oracle’s price list notes that nearly all modules require the Siebel CRM Base license as a prerequisite. Some niche add-ons (like certain connectors or tools) might be exceptions, but generally, you must license and add the modules you use. All customers can mix and match CRM modules and even industry modules as needed in their solution.
Siebel Licensing Metrics and Models
Oracle Siebel’s licensing model defines how usage is measured and priced. The main license metrics for Siebel’s and capacity-based licenses, with a few variations:
- Application User: A Named User license tied to an individual authorized to use a specific Sion. Each person with a Siebel login (employee or internal user) counts as an Application User, regardless of how often they use the system. For example, if 150 employees have Siebel accounts, you need 150 Application User licenses (even if some are is). Licenses cannot be shared; one license = one person. This metric is common for core modules like Sales, Service, Marketing, etc., and essentially means per named user per module. Important: Application User licensing requires counting every individual with access, so inactive accounts are disabled to avoid license requirements (more on compliance risks below).
- Named User Plus (NUP): Another form of named user license, similar to Application User but with Oracle’s standard “plus” definition. A Named User Plus includes human users and non-human devices or scripts that access the software. Or if you use any multiplexing or pooling (like a web portal that many users access via a single technical account), you must count each end-user behind it. NUP is essentially a stricter named-user metric ensuring all usage (human or automated) is covered. Oracle also enforces a minimum number of NUP licenses if you use this metric (to prevent undercounting on powerful servers). NUP can license Siebel products in many cases, and this metric is a User in practice – the distinction is more about Oracle’s countingerm used in many Oracle apps, whereas NUP is a generic Oracle metric; for Siebel, the effect is similar: each unique user needs a license.)
- Registered User: A specialized named user metric for external users (partners or customers).. Registered User licenses are typically used for Siebel partner portals or customer self-service scenarios. Only non-employees qualify as Registered Users. This metric allows you to license external y different pricing from internal users. For example, 100 partner portal users might be licensed as 100 Registered Users of Siebel PRM. Oracle’s rule for partner applications is that certain add-ons for partners cannot exceed the count of base partner users licensed (e.g. you cannot license 50 Partner Commerce users if you only have 30 Partner Portal users licensed – the add-on must be equal or fewer, to mirror your base count or (CPU) License: A license based on server processing power rather than named individuals several processor licenses to cover each core/processor running the Siebel software (usinfactor table for multi-core CPUs). Processor licensing allows unlimited users on that server, which is useful if user counts are very high or indeterminate (for example, a public-facing would be impractical). Organizations choose the processor metric when the number of actual users is very large or fluctuates, so counting named users is difficult. Note: Oracle requires you to license all processors where Siebel is installed/operational – including production and applicable non-production environments – and maintain minimum NUP-to-processor ratios if you mix metrics. Processor licensing can be expensive but provides flexibility for unlimited user access on the licensed hardware.
- Enterprise License / Unlimited License Agreement (ULA): In some cases, Siebel may be licensed under a broader enterprise agreement. Oracle might bundle Siebel modules in a Custom Application Suite or offer an unlimited usage license for a fixed price. For example, large enterprises might have a suite where a certain number of users can access multiple Oracle applications (Siebel included) under one combined metric (often called a ser). Alternatively, Siebel could be included in an Unlimited License Agreement for a period, allowing unlimited deployment of specified Siebel components enterprise-wide. These enterprise deals are typically negotiated for large Siebel estates or as part of a wider Oracle product bundle. They can simplify licensing on paper, but it’s crucial to understand their terms (often time-bound and with certification requirements, in the case of ULAs).
Historical Note – Concurrent Users:
Siebel historically offered a Concurrent User metric (especially for external-facing modules) in the pre-Oracle days. This allowed a pool of users with a limit on simultaneous logins. Oracle has since retired concurrent licensing for Siebel, and new licenses are only sold as named user or processor. Suppose you have old concurrent-user licenses (grandfathered from legacy ). In that case, you may continue to use them within their limits, but exceeding those limits even once voids that model and forces migration to named user metrics.
Oracle audits will treat concurrency overage as a compliance gap requiring conversion to current metrics (which can be costly). Thus, any legacy concurrent licenses should be closely monitored, and ideally, a plan should be made to transition to NUP or processor to avoid compliance traps.
Licensing Structures: Perpetual vs Term, Support Entitlements, On-Premises vs Cloud
Oracle Siebel is predominantly licensed under a traditional on-premises perpetual license model. Key aspects of the licensing structure include:ual Licenses:** A perpetual license grants the right to use the Siebel software indefinitely (perpetually), typically for a one-time license fee per metric (per user or processor), plus annuals.
Once purchased, you can continue to run that Siebel version forever, even if you stop paying support (though you’d lose access to update support in that case). Most Siebel modules (Sales, Service, etc.) are sold as perpetual licenses, so understanding the user counts and modules needed upfront is critical.
After Oracle acquired Siebel, Siebel CRM became part of Oracle’s “Applications Unlimited” commitment. This means Oracle continues to offer and support Siebel on-premise indefinitely rather than forcing cloud migration. Thus, perpetual on-premises use will remain common for Siebel customers in 2025.
License Bundles & Suites:
Besides individual module licenses, Oracle sometimes provides Siebel in bundled structures for convenience. For example, a Siebel Custom Application Bundle or Custom Application Suite might allow you to pick a bundle of Siebel modules under one licensing metric. In such a case, you pay for several users who can access a defined set of modules rather than licensing each module a la carte.
This can simplify licensing if you use many Siebel modules together. These bundles are often negotiated case-by-case. Additionally, some Siebel packages might come with prerequisites – e.g., Oracle might mandate a minimum number of base CRM users before you can license certain add-ons (ensuring a baseline revenue).
When planning your license acquisition, always check the price list and licensing guide for any prerequisites or minimums. Learn about licensing rules, key considerations when choosing licenses, and common pitfalls organizations should avoid.
Term Licenses (Subscription):
Oracle also offers term or subscription licensing for some products. A term license for Siebel would be a time-limited right to use (e.g., 1-year, 3-year, or 5-year term) for a lower upfront cost, which expires if not renewed. In practice, term licensing for Siebel is less common than perpetual but may be used in specific cases or bundled deals. A term license often includes support for the term by default (since you pay annual fees as part of the subscription).
The cost structure might be a percentage of the perpetual price (for example, a 1-year term might cost ~20–25% of the perpetual license fee, aligning with Oracle’s standard pricing models).
Organizations might consider term licensing if they have short-term projects or are uncertain about long-term Siebel usage. However, due to Siebel’s critical role and long implementation cycles, most enterprise Siebel deployments have been perpetual investments.
Support & Maintenance:
Oracle support is crucial whether you have perpetual or term licenses. Annual support fees (for perpetual licenses) are typically ~22% of the license purchase price, paid yearly. This grants access to product updates, patches, and technical support. Support also entitles you to upgrade to newer Siebel versions without buying new licenses.
For Siebel, staying on support is important if you need Oracle’s help or plan to apply patches; however, it is also a significant ongoing cost. If you stop paying support on perpetual licenses, you can still use the software at the last version you were entitled to, but you lose Oracle’s assistance and legal right to upgrades.
Many organizations have sought to reduce Siebel support costs due to Siebel being stable/mature software – strategies for this are discussed later (including third-party support options). It’s worth noting that Oracle typically increases support prices by a small percentage annually (unless locked by contract) and that dropping support and re-enrolling later can incur back-support fees, so decisions around support need to be made carefully.
On-Premises vs Cloud Deployments:
Siebel CRM is fundamentally deployed on your own servers or cloud infrastructure. Oracle does not offer Siebel as a multi-tenant SaaS service; instead, Oracle’s cloud CRM offerings (like Oracle CX Cloud or former Siebel CRM OnDemand) are separate products, which we are not covering here.
However, you can deploy Siebel on Oracle Cloud Infrastructure or AWS using your licenses – a Bring Your Own License model. The licenser remains the same (you must license the VMs or servers by processor or the users by name). So, cloud vs. on-prem for Siebel is mostly about infrastructure: it doesn’t change Siebel’s licensing metric since you use your on-prem licenses even in the cloud.
Oracle has encouraged customers to consider moving to its cloud CRM solutions, but many enterprises continue to run Siebel due to heavy customization and data integration on-prem.
Bottom line: This guide assumes you are licensing Siebel for on-premises use (whether on physical or IaaS cloud servers). If you did opt for Oracle’s cloud subscription (a different CRM product), the licensing would be subscription-based per user/month, but that’s outside the scope of Siebel licensing itself.
Read our Siebel Licensing FAQs.
Key Siebel Compliance and Audit Risks (and How to Mitigate Them)
Managing Siebel licenses in a large environment is challenging, and several common compliance pitfalls can lead to costly surprises during an Oracle audit. Oracle’s License Management Services (LMS) is aware of these issues and often targets them in Siebel audits. L-specific risks include:
- Orphaned Users (Not End-Dating Inactive Accounts): Siebel’s user-based licensing means every individual with access requires a license. A common mistake is failing to promptly remove or “end-date” user accounts when people leave or change roles. This results in more named users than necessary – effectively over-licensing yourself and risking non-compliance if you haven’t purchased enough licenses. Example: A company had 300 Siebel user accounts, but 50 were for ex-employees not removed; Oracle would still count 300 named users against their licenses. If only 250 licenses were purchased, 50 would be unlicensed usage.
Mitigation: Implement regular user access reviews and tie Siebel to HR offboarding processes. Ensure any user who no longer needs Siebel is promptly deactivated. Periodically reconcile Siebel’s active user list with your license entitlement to catch discrepancies early. - Access to Unlicensed Modules: Out-of-the-box, Siebel does not technically prevent an admin from granting access to any module (all modules are unlocked by default). This means it’s possible to start using a Siebel module for which your organization hasn’t purchased licenses. Example: An admin might enable the Siebel Marketing module for a team, not realizing the company is only licensed for Sales and Service. During an audit, Oracle would flag all users accessing Marketing as unlicensed usage.
Mitigation: Use role-based controls to restrict access only to licensed modules. Document which modules your company owns and train Siebel administrators not to turn on features or responsibilities tied to modules outside that list. Perform periodic permission reviews to ensure that no one has inadvertently been given access to an unlicensed component. - Unintended Use via Customizations (Custom Views/Integrations): Siebel is highly customizable, but custom configurations can accidentally dip into the functionality of other modules. For instance, a custom view or report might pull data from Siebel Analytics or another module your company didn’t license. Example: Your team creates a custom dashboard combining Siebel Service and Siebel Loyalty data. If you’re only licensed for Service, using that dashboard means indirectly using Loyalty features without a license.
Mitigation: Map each custom view or integration to the Siebel modules it leverages. Document all custom components and which modules’ data or APIs they use. If there’s any ambiguity, consult Oracle or a licensing expert to see if an additional license is required. Also, Oracle LMS provides tools to detect usage of specific module components, so do your internal check (for example, review if any “unowned” module tables or business components are being accessed). - Unlicensed Non-Production Environments: A frequent misunderstanding concerns development, test, or disaster recovery environments. Oracle’s policy is that all environments must be licensed. Using Siebel in a dev/test environment without proper licenses is non-compliant. Under standard terms, there’s no free ride for non-prod usage.
Example: If you have a separate test Siebel server used by five testers who don’t have production accounts, those five need licenses (or you need the test server in processor licensing). Oracle sometimes allows limited use on a cold disaster recovery server without a license (e.g., if it’s only used in failover for less than 10 days a year). However, that’s a specific exception and must align with Oracle’s policies.
Mitigation: Treat non-prod servers the same as prod in license planning. If the same named users access both prod and test, you might be covered (since those users’ licenses cover any environment). But if there are additional users or separate servers, account for them. Include dev/test in your regular compliance audits. Clarify in contracts if any special terms apply to non-prod (sometimes customers negotiate lab use rights or discounted licenses – absent that, assume full licensing is required). - Mixing License Metrics Improperly: Oracle expects a given Siebel deployment/module to be licensed under one metric. Some companies try to mix metrics (e.g., cover some users with named user licenses and then add a processor license for extra capacity on the same instance). This is generally not allowed and leads to confusion in audits.
Example: You have 100 named user licenses for Siebel Sales but 120 active users. You then buy a processor license, thinking it will cover the excess 20. In reality, Oracle would consider the entire instance processor-licensed (unlimited users) and also likely still enforce a minimum of 25 NUP per processor – meaning your 100 NUP might be seen as insufficient if, say, two processors are in use (would need 50 NUP min). The mix doesn’t work as a way to reduce counts.
Mitigation: Stick to one primary metric per module/environment. If you need to switch metrics (e.g., moving from user-based to processor due to growth), do it in a coordinated way with Oracle – often they will credit your existing licenses into a new arrangement rather than running both simultaneously. An acceptable form of “mixing” is using different metrics for clearly separate modules: e.g., license internal users on a Sales module with Application User, but license an external customer portal module by Processor. In an audit, Oracle will match usage to entitlements; clear boundaries (with documentation) will help show that each user population is properly covered. - Specialty Metrics Overlooked: Some Siebel modules (especially industry solutions or specific functionalities) use non-user metrics. For instance:
- Electronic Order Lines: Siebel Order Management may require licensing each external order line submitted via EDI/XML rather than a user】.$M Revenue: Siebel Self-Service eBilling might be licensed by revenue managed through the system.# of Claims: Siebel insurance modules could be measured per number of claims processed.
Mitigation: Review the Oracle Siebel price list or licensing guide for any metric tied to transactions or data volume in your modules. Monitor your usage against those metrics (e.g., if you licensed 10,000 claims per year and the business plans to double claims processing, you need to true up proactively). Non-compliance here might show up in an audit through LMS data requests (Oracle could ask for the number of order transactions processed, etc., if those modules are in scope). - Third-Party Access Under Wrong Licenses: Siebel’s Registered User metric distinguishes external users (partners/customers) from internal users. A compliance issue arises if a company gives partners access to Siebel via internal (cheaper) licenses. In an audit, Oracle will scrutinize user lists; if non-employees use employee licenses, that’s a violation.
Mitigation: Classify users correctly (employee vs. partner vs. customer) and ensure you have the corresponding license type for each. Don’t try to save money by letting 50 partners use up some of your internal user licenses—that’s not permitted. If budget is a concern, consider a processor license for large external user bases.
Oracle LMS Audit Behavior:
If Oracle initiates a Siebel audit (either by Oracle LMS or a certified partner auditor), expect a formal request for data. Typically, Oracle will ask you to run LMS scripts or queries on the Siebel database to gather evidence of usage.
They may request a list of all Siebel users and their last login dates, a list of responsibilities (roles) (to infer module access), configuration files indicating enabled modules, and server specifications (for processor counts). Oracle audits often cover multiple products, so Siebel could be part of a broader license review (e.g., they audit Database, Middleware, and Siebel together).
Notably, Oracle has fewer auditors specializing in Siebel than Database or Java (Siebel audits are less frequent, but that doesn’t mean they won’t happen – particularly if your Siebel support has lapsed or usage is suspected to have grown). During an audit:
- Oracle will match the data from your Siebel system to your contract entitlements (they’ll ask you to provide your Siebel license order documents for what you’ve purchased).
- Any gap (more users than licensed, unlicensed module usage, missing non-prod licenses, etc.) will be summarized in a compliance report, usually with backdated license fees and support for any shortfall.
- Oracle’s audits can claim back support fees for the period of unlicensed usage, which can significantly inflate the settlement. They could even threaten termination of support or licenses for breach (though they typically prefer to resolve via selling you additional licenses).
Being prepared via internal audits is crucial. Run Oracle’s Siebel LMS scripts internally before an official audit to see what they would find. This lets you address any issues proactively on your terms.
Real-World Siebel Licensing Missteps and Audit Findings
To illustrate the above risks, here are some real-world scenarios and lessons learned:
- Inactive Users Leading to Audit Findings: Oracle audited a large telecom company and found hundreds of Siebel user accounts belonging to former employees. Because these accounts were never deactivated, Oracle’s audit report counted them as requiring licenses – pushing the company 20% over its purchased license count. The result was an unexpected compliance bill in the millions. Lesson: The company established a policy to immediately remove Siebel access when staff exits and to run a quarterly script listing all active Siebel IDs to ensure the count stays within purchased limits. This practice helped avoid “shelfware” and made true-ups more predictable.
- Unlicensed Module Usage – Siebel Marketing Example: A financial services firm had Siebel Sales and Service licenses in another case. However, unaware of licensing, a new marketing team member enabled the Siebel Marketing module and started using it for campaigns. In the next Oracle audit, LMS scripts detected data and objects related to Siebel Marketing in the system. Oracle flagged this as unlicensed use of Siebel Marketing for all users with access to that d to purchase Siebel Marketing licenses for those users after the fact and pay support back fees. Lesson: Although the software allowed them to turn it on freely, the legal right was not there. The firm now locks down roles so only modules that are paid for are visible to users, and any expansion of functionality must pass through a licensing check by IT governance.
- Siebel and Non-Prod Environment Licensing: A global manufacturing company ran a full clone of Siebel for testing/training with dozens of test-only user accounts. They assumed their production Named User licenses would cover it. Still, an Oracle audit insisted that those test user accounts also required licenses (since they were different individuals who didn’t have production access). The company had to buy extra licenses to cover those test users – an unbudgeted expense. Lesson: They negotiated in their next contract renewal to include rights for up to X test users at a discounted rate, and in the meantime, they limited test environment access to only those who also had production access, consolidating license needs.
- Compliance Cost and Support Savings (Case Study): A well-publicized case involved a company facing a $22 million compliance gap in Siebel and related licenses. With expert help, they optimized their licensing (removing unnecessary users, reconfiguring some deployments) and moved Siebel to a third-party support provider. Doing so, they negotiated support fees at roughly 30% of Oracle’s standard rate (saving 70% on annual support costs). The immediate compliance issues were settled, and over three years, they saved about $6 million in support fees. Lesson: For stable, long-running Siebel systems that are not expecting major upgrades, third-party support can be a viable way to cut costs – but it’s vital to ensure compliance before leaving Oracle support. Once-off support audits may be less frequent, but you must maintain discipline in license management since you won’t have Oracle advising you of issues through support channels.
- Concurrent to Named User Migration Gone Wrong: A company had legacy Concurrent User licenses (from early 2000s contracts) for a Siebel partner portal. As their usage grew, they occasionally exceeded the concurrent limit. Oracle eventually noticed (through a support engagement) that peak concurrent users surpassed the licensed number, effectively voiding the old agreement. Oracle required them to transition to Named User licenses for all partner users, leading to a significant cost increase. Lesson: Treat the limit as a hard ceiling if you still use concurrent licenses. Consider negotiating a conversion to modern metrics before an inadvertent breach forces it. Oracle may offer conversion credits; do it on your terms rather than during an audit when leverage is low.
Strategies for Optimizing Siebel License Use and Reducing Costs
Despite Siebel’s complexity, organizations can take strategic steps to optimize license usage and minimize costs:
- Regular Internal License Audits: Don’t wait for Oracle. Conduct your license reviews at least annually. This can include running Oracle’s LMS collection queries or using a software asset management (SAM) tool to gather Siebel usage data. Check user counts vs entitlements, modules in use vs owned, and any changes in infrastructure (new servers added, etc.). Internal audits help catch issues early, allowing you to true-up or adjust before it becomes an official audit finding. Maintain an internal “Effective License Position” document for Siebel, updated with each change.
- User Access Governance: Implement strong joiner/mover/leaver processes for Siebel. Whenever new users are given access, ensure you have a license available for them (or procure one). When users leave or no longer need Siebel, remove them promptly. Consider integrating Siebel with an identity management system so that account provisioning/de-provisioning is automated and tied to HR events – this prevents the buildup of idle accounts consuming licenses. Also, leverage Siebel’s usage tracking (last login data) to flag dormant accounts that might be candidates for removal or license recycling.
- Module Usage Monitoring: Use Siebel’s audit trail and usage logs to monitor what modules and features are being accessed. If certain licensed modules are under-used, you might consider reducing their footprint (or not renewing support on those licenses to save cost). Conversely, if unlicensed features are being used (even inadvertently), either restrict them or plan to license them. Having transparency on actual usage allows optimization – e.g., you might discover that only 50 of your 100 Siebel Marketing licenses are actively used, which could inform contract negotiations (maybe you can drop some licenses if not needed, or at least avoid buying more).
- License Recycling and Pool Management: Since Siebel Application User licenses are named-user but not tied to a specific individual forever, you can reassign licenses as people change. Manage a pool of available licenses. For example, if 10 users left and freed up licenses, document that so you can onboard 10 new users without buying more. Keep an eye on the peak number of active users over time – that’s what Oracle will measure in an audit. If your active named users peaked at 500 last year, that’s the compliance bar, even if day-to-day only 450 use it. So plan license counts around peak usage with a buffer for new projects.
- Infrastructure Planning (Processors and Environments): If using processor licensing, closely monitor where Siebel is installed. Adding a new application server node in a cluster or moving to a server with more CPU cores could change your required licenses. Optimize by using technologies like virtualization wisely – e.g., if you can pin Siebel to specific CPU cores or a specific virtual machine size, you can limit the number of processors you need to license. Oracle’s rules on partitioning can be strict (soft vs hard), but it’s worth architecting with licensing in mind to avoid surprise costs. For non-prod, consider using the same licensed infrastructure for multiple purposes (if feasible) to avoid licensing many separate servers. For instance, some companies use a time-sharing approach for training vs test vs dev on one environment to limit the number of distinct installations they must license (not always possible, but worth creative thinking).
- Retire Unused Modules/Licenses: Over the years, businesses change. Maybe a Siebel module was deployed and later replaced or no longer needed. If you have licenses and support for modules you’re not using, evaluate whether to drop support (to save the annual maintenance cost) or repurpose the licenses elsewhere if possible. Oracle typically doesn’t let you “sell back” licenses, but you can choose not to renew support on shelfware licenses (just beware that if you need them again, you’d have to buy new licenses). Dropping support means you lose upgrade rights for that component – ensure it’s unnecessary. In some cases, consolidating to fewer modules and standardizing on those can reduce the overall license footprint (especially if overlapping functionality exists).
- Third-Party Support or Oracle ULA Consideration: For organizations looking to significantly cut costs, and if the Siebel system is in a steady state (no major upgrades planned), moving to a third-party support provider can yield 50-70% savings on support fees, as noted earlier. Firms like Spinnaker, Rimini Street, etc., specialize in supporting Oracle applications outside of Oracle’s umbrella. This means you pay them a lower fee and stop paying Oracle Support. The risk is that you won’t get new patches or enhancements (which for Siebel might be acceptable if you’re on a stable version). Also, Oracle may still audit you, so you must remain compliant with license counts (third-party support doesn’t shield you from the license contract itself). Ensure you’ve addressed any compliance gaps before switching since Oracle may be less willing to negotiate after you leave their support. Another strategy, if growth is expected, is negotiating an Unlimited License Agreement (ULA) or an enterprise license. This is only viable for very large deployments, but it can temporarily remove license-count worries (you pay a big fee for 3 years of unlimited Siebel usage). At the end, you certify usage. This can be complex, but some enterprises with expanding Siebel usage consider it to avoid incremental purchases every year.
- Training and Awareness: It might sound basic, but ensure all stakeholders understand Siebel licensing rules – not just the IT asset manager but Siebel administrators, project managers, and procurement. Many compliance issues happen because someone in IT or the business wasn’t aware that spinning up a new instance or giving access to an X feature had license implications. Regular training or at least a quick reference guide internally can help. For example, before a new Siebel feature is enabled, “Do we have a license for this?” should be standard. Oracle’s licensing policies evolve, so staying current (via Oracle’s official price lists, or advisors like Gartner, or Oracle licensing consultants) is part of the ITAM role.
Oracle LMS Audit Expectations for Siebel
When facing an Oracle audit specifically involving Siebel, here’s what to expect and prepare:
- Data Collection: Oracle LMS will typically provide scripts or a questionnaire. For Siebel, they might send SQL scripts to run on the Siebel repository or ask for administrative reports. Expect to furnish:
- A full list of Siebel users, their user type (employee, partner, etc.), and status.
- A list of all responsibilities (roles) and possibly which modules those map to. Oracle might correlate certain responsibilities with certain modules (e.g., if users have “Marketing User” responsibility but you didn’t buy Marketing, red flag).
- Instance details: number of Siebel environments (prod, test, dev, DR), their hostnames, and the processors/cores for each.
- Configuration files showing enabled components or logs indicating which modules have been accessed.
- LMS Scripts: Oracle might use a one-size-fits-all LMS script package that includes database options, etc. While Siebel is an application, not a database, the concept is similar: the scripts gather usage data. These scripts can reveal even historical usage (e.g., a user created and later deleted might still appear in some audit trail). So, cleaning up just before an audit might not erase all traces. It’s better to be consistently clean.
- Audit Timeline: Generally, there’s a kickoff, data gathering (you usually have 2-3 weeks to run scripts and return data), then analysis by Oracle, and then they present findings. The timeline could stretch over months with Siebel because it’s often part of a larger audit. Oracle may ask clarification questions in between (e.g., “We see 50 users with a ‘Marketing’ responsibility, do you have licenses for Siebel Marketing?” – if not, that’s a finding). Be truthful and precise; if you realize a mistake (like you find those 50 users shouldn’t have that role), you can remediate by removing access during the audit. However, Oracle may still count it as usage during the audit period.
- Compliance Report and Resolution: The result of an audit is a report listing any shortfalls. For each compliance gap, Oracle will cite the contract clause and number of licenses owed. They will often propose that you purchase those licenses (at the list price, possibly with a discount if negotiated) plus back support. They might alternatively charge a fee for unlicensed use (though typically they push license sales). Negotiation at this stage can sometimes reduce penalties, but companies usually have more leverage before the audit (in preventing issues) than after. Therefore, all the best practices above serve to avoid a painful report.
- LMS Behavior: Oracle LMS (now often called Oracle GLAS – Global License Advisory Services) publicly states that they are there to help customers remain compliant. But it’s well known that audits are also revenue-generating. About 20-30% of Oracle audits result in findings that translate to sales opportunities for Oracle’s field sales. As such, treat an audit seriously; engage your procurement and legal teams. Every communication should be carefully managed (it’s often advisable to have all audit correspondence in writing). Also, suppose Oracle uses a third-party auditor (under the Oracle PartnerNetwork Authorized LMS program). In that case, the auditor is incentivized to find non-compliance (they often get a cut of resulting sales). Always review any claimed findings in detail – sometimes scripts can be wrong or misinterpreted. For instance, if Oracle’s script counts 300 users but you know 50 are test duplicates, you can argue those shouldn’t count if they’re the same named person, etc. Having thorough internal records and following best practices makes defending your position much easier.
Best Practices for Managing Siebel in Large Enterprises
Finally, consolidating the advice, here are best practices and recommendations for IT asset managers, procurement teams, and Siebel admins managing an enterprise Siebel estate:
1. Maintain Clear License Records:
Keep a centralized repository of all Siebel licensing documentation – contracts, Oracle Ordering Documents, proof of purchases, support renewal quotes, etc. During personnel turnover, ensure this knowledge is passed on. Know your entitlements (e.g., 500 Siebel Sales Application User licenses, 200 Siebel Service, 2 Siebel Processors for customer portal, etc., plus any special terms).
This helps avoid overspending and under-licensing. Also, track your support renewals—sometimes, products get dropped from support by mistake, or support SKUs change; align them with what’s deployed.
2. Engage Stakeholders in Governance:
Form a governance team for Siebel that includes ITAM, the Siebel application owner, and business representatives. Review any planned changes (upgrades, new integrations, additional user groups) to assess the impact of licensing.
For example, suppose the business wants to open a new self-service portal for customers. In that case, governance should decide how to license it (do we buy Registered User licenses or a processor license? How many?). This proactive approach prevents project teams from unknowingly causing compliance issues.
3. Optimize Contracts During Procurement:
When negotiating with Oracle (or at annual support renewal time), leverage what you know about your usage. If you only use 300 of 500 licenses, you might be unable to return them. Still, you could attempt to migrate some to another module you need more or negotiate a broader agreement that gives flexibility.
Oracle sales reps often can offer deals like a Custom Application Suite user license that covers multiple modules – sometimes at a better price than buying each module separately if you truly need many modules for each user. Also consider negotiating clauses for things like:
- “Failover rights” for DR servers (so you don’t need to license the standby).
- Development license discounts (some customers negotiate lower-cost dev licenses at 75% off, given they’re not production – not an Oracle standard, but negotiable).
- Audit process agreements: While Oracle probably won’t change their audit clause, you can sometimes get them to agree to provide assistance or a grace period to resolve issues before formalizing an audit finding.
- If you foresee a reduction in Siebel usage (maybe due to a future migration), try to negotiate shorter-term or more flexible arrangements rather than being stuck with shelfware. Conversely, if usage is growing, negotiate prices for future licenses now (caps on increases).
4. Regular Training and Audit
Drills: Conduct internal workshops on licensing dos and don’ts for your Siebel admins and business power users. Perhaps annually, run a mock audit: Have your team pretend to be Oracle LMS and see if they can find any compliance gaps in your Siebel deployment.
This not only educates the team but keeps everyone vigilant. It’s much better to find an issue yourself in a drill than have Oracle find it officially.
5. Use Technical Controls to Enforce Licensing Policy:
Whenever possible, configure Siebel to technically limit what’s not licensed:
- Remove unlicensed modules from the GUI (so users don’t even see that the Marketing module exists if you didn’t buy it).
- Implement data-level controls. For example, if you are licensed for 100k transactions/year of a certain type, maybe set up an alert in Siebel or an external monitor when approaching that threshold.
- Monitor admin actions: If an admin tries to create a responsibility related to a new module, have a checklist where they must confirm license procurement.
6. Stay Informed on Oracle Policies and Siebel’s Roadmap:
Oracle licensing rules can change (though Siebel’s have been stable recently). Still, keep an eye on Oracle’s official price list updates and any Oracle communications about Siebel. Also, be aware of Siebel’s product roadmap – Oracle continues to release updates (Siebel CRM is now in version 21.x+ continuous release model).
New features might be included under existing licenses or sometimes introduced as new licensable options. If you plan to adopt a new Siebel feature, double-check if it requires any new licenses. Subscribe to user groups or forums where licensing is discussed, or consult with licensing experts if uncertain.
7. Plan for License True-ups or Retirement:
If your organization plans to eventually phase out Siebel (which is common in some digital transformation initiatives), manage your licenses accordingly. You might not want to buy a multi-year license extension if you plan to decommission in 2 years—maybe a shorter-term deal or even a transition to cloud credit (Oracle sometimes allows converting on-prem support into cloud credit, although Siebel cloud equivalents are separate products).
If Siebel remains core, expansion plan: Perhaps buy a few extra licenses as a buffer (cheaper to buy at a planned juncture than during an audit). If you reduce usage, consider dropping support on those portions when possible to save cost (with the understanding that you can’t legally use those dropped portions in production).
Managing Oracle Siebel licensing is about continuous oversight and strategic planning. With diligent user management, clear understanding of license metrics, and proactive governance, you can avoid the common compliance traps and keep costs under control. Siebel may not be the shiny new SaaS product.
Still, it often runs critical business processes – treating its license management with the same rigor as any major IT asset is essential. By following the best practices outlined above, ITAM and procurement leaders can ensure their Siebel investments deliver value without unwelcome surprises and remain prepared for any Oracle LMS inquiries that come their way.
When licensing an industry-based option, check that industry module section for a replacement. n. (e.g., if the customer licenses the Communications, Media & Energy base option and they want contract functionality, they should license Siebel CME Contracts, not Siebel Contracts
Siebel Licensing Definitions
Application User: is defined as an individual authorized by you to use the applicable licensed application programs installed on a single server or multiple servers regardless of whether the individual is actively using the programs at any given time.
Suppose you license the Oracle Self-Service Work Request option with Oracle Enterprise Asset Management. In that case, you are required to maintain licenses for the equivalent number of Application users licensed. You are granted unlimited access to initiate work requests, view work request status, and view scheduled completion dates for your entire employee population.
For Order Management, application users can manually enter orders directly into the programs, but any orders entered electronically from other sources must be licensed separately by the Electronic Order Line.
$M in Application Annual Revenue is one million U.S. dollars, excluding taxes processed through the licensed program. For Oracle Self-Service E-Billing products, the Annual Revenue is equivalent to the total invoiced amount for all company accounts with at least one enrolled user per billing period.
1,000 Claims: This is defined as one thousand unique claims processed through the program over 12 months. A unique claim is defined as one of the following: OEM Claims entry, supplier claims entry, and adjudication. Claims flow through to OPA for automated processing. You may not exceed the licensed number of transactions during 12 months unless you acquire additional licenses from Oracle.
Customer Record: is defined as each unique Customer Record (including contact records, prospect records, and records in external data sources) that you may access using the program
Electronic Order Line: is defined as the total number of distinct electronic order lines entered electronically into the Oracle Order Management application from any source (not manually entered by licensed Order Management Users, Professional Users 2003, or Professional Users 2003 External) during 12 months. This includes order lines originating as external EDI/XML transactions and/or sourced from other Oracle and non-Oracle applications. You may not exceed the licensed number of order lines during 12 months.
Employee: Enterprise Employee is defined as (i) all your full-time, part-time, and temporary employees, and (ii) all of your agents, contractors, and consultants who have access to, use, or are tracked by the Oracle Programs. The number of licenses required is determined by the number of Enterprise Employees and not the actual number of users. In addition, if you elect to outsource any business function(s) to another company, all of the company’s full-time, part-time, temporary employees and agents, contractors, and consultants that are providing the outsourcing services for you who have access to, use, or are tracked by the Oracle Programs must be counted to determine the number of Enterprise Employees.
Named User Plus / Named User is defined as an individual authorized by you to use the programs installed on a single server or multiple servers, regardless of whether the individual is actively using the programs at any given time. All of the remaining provisions of this definition apply only to Named User Plus licenses and not to Named User licenses. A nonhuman-operated device will be counted as a named user, plus all individuals authorized to use the programs if such devices can access the programs. If multiplexing hardware or software (e.g., a TP monitor or a web server product) is used, this number must be measured at the multiplexing front end. Automated batching of data from computer to computer is permitted. You are responsible for ensuring that the named user plus per processor minimums are maintained for the programs in the minimum user table in the licensing rules section; the minimums table provides for the minimum number of named users plus required, and all actual users must be licensed.
Partner Organization is an external third-party business entity providing value-added services in marketing and selling your products. Depending upon the type of industry, partner organizations play different roles and are recognized by different names, such as resellers, distributors, agents, dealers, or brokers.
Registered User: is defined as an individual authorized by you to use the programs installed on a single server or multiple servers, regardless of whether the individual is actively using the programs at any given time. Registered Users shall be only your business partners and/or customers, not your employees.
Siebel – Compliance Risks
Managing Oracle Siebel licensing can be complex, and non-compliance can lead to costly issues. Below, we highlight some of the most common compliance risks and provide practical solutions to help you stay compliant.
1. Not End-Dating Users
License Model:
Siebel follows an Application User licensing model, which means every individual authorized to use Siebel requires a license, regardless of whether they actively use it.
Compliance Risk:
Many companies become non-compliant by not end-dating users who no longer need access to Siebel. This leads to more users appearing as “licensed” than the company needs, resulting in costly over-licensing issues.
Example:
Imagine a company with 300 Siebel users. Over time, 50 employees leave or change roles. If their access is not properly revoked, Siebel will still count them as licensed users, pushing the number of licenses beyond what is required.
How to Mitigate This Risk:
- Regular User Reviews: Conduct regular audits to identify and deactivate users without access.
- Automated Deactivation: Use tools that integrate with HR systems to automatically revoke access when an employee leaves.
- Quarterly Licensing Audits: Regularly compare active users with your licensed count to identify discrepancies early.
2. Access to Unlicensed Modules
How It Happens:
In Siebel, all modules are unlocked by default. No serial keys or pre-purchase validations are required, which makes it easy for administrators to unknowingly access modules for which the company doesn’t have a license.
Compliance Risk:
Siebel administrators can mistakenly grant access to modules other than those covered by the company’s license, which can lead to potential licensing violations.
Example:
Consider an administrator who grants access to the Siebel Marketing Module despite the company only holding licenses for the Sales and Service modules. Such unauthorized access could lead to unexpected compliance audits and fines.
How to Mitigate This Risk:
- Set Clear Access Controls: Restrict access to the modules your company has licensed by configuring role-based permissions.
- Regular Module Usage Reviews: Periodically audit the modules used to verify they match what has been purchased.
- Training for Administrators: Educate your Siebel admins on what modules are licensed and ensure they understand the compliance implications.
3. Use of Custom Views
Risk of Custom Views:
Developing and using custom views in Siebel can inadvertently lead to non-compliance if those views utilize Siebel products or modules for which you lack licenses.
Compliance Risk:
Custom views often pull data or functionality from modules other than those your organization has purchased. Without proper mapping, you may unknowingly leverage Oracle functionality outside your licensed scope.
Example:
Your development team creates a custom report that combines data from both Siebel Sales and Siebel Analytics modules. If your company only has a license for the Sales module, this could trigger a compliance breach.
How to Mitigate This Risk:
- Map Custom Views to Modules: Ensure each custom view is mapped to the specific Siebel products it utilizes.
- Documentation and Review: Thoroughly document all customizations and periodically review them to confirm they comply with licensing rules.
- Use Oracle LMS Tools: Leverage Oracle’s License Management Services (LMS) tools to validate that custom views are within the licensed boundaries.
Best Practices for Siebel Compliance
- Frequent User Audits: Regularly audit user access and end-date inactive users to avoid accumulating unnecessary licenses.
- Access Restriction: Limit access strictly to modules your organization has licensed.
- Admin Education: Train administrators on Siebel licensing requirements and conduct periodic compliance workshops.
- Custom View Documentation: Document customizations and ensure they adhere to licensed product boundaries.
By proactively addressing these risks, you can avoid compliance pitfalls, reduce unnecessary costs, and ensure the smooth operation of your Siebel deployment.
FAQs on Siebel Licensing
What are the main types of Oracle Siebel licenses?
Oracle Siebel licenses are categorized into Named User Plus (NUP), Application User, Processor, and Enterprise. Each type serves different purposes based on access requirements, the number of users, or the processing power needed.
How do Processor licenses work for Siebel?
Processor licenses are based on the number of processors running Siebel software. This model is often used when it’s challenging to determine the exact number of users or when user numbers may vary significantly. It provides a way to license Siebel based on system capacity rather than user count.
What are the Enterprise licenses for Siebel?
Enterprise licenses provide broad access to multiple Oracle products, including Siebel. Large organizations generally use these licenses with a wide array of Oracle solutions.
What is the Siebel Custom Application Bundle?
The Siebel Custom Application Bundle is a licensing model that allows organizations to license only the specific Siebel applications they need rather than purchasing the entire suite. This model is particularly beneficial for companies that require a tailored licensing approach.
What are the compliance risks associated with not end-dating users in Siebel?
Not end-dating users who no longer need access can lead to over-licensing. Siebel counts all authorized users, and if inactive users are not deactivated, a higher number of licenses is required than necessary, which can be costly.
How do companies typically end up using unlicensed Siebel modules?
Siebel installations have all modules unlocked, and administrators can easily grant access without needing serial keys or pre-approval. This often leads to modules being accessed that the organization has not paid for, resulting in compliance risks.
What are custom views, and how do they impact Siebel licensing compliance?
Custom views in Siebel are tailored interfaces or reports created by the user. They can unintentionally draw upon modules or data the organization is not licensed for, leading to compliance issues. Each view needs to be mapped to ensure it only utilizes licensed modules.
What should be included in a regular Siebel licensing audit?
A regular Siebel licensing audit should include reviewing user access to ensure inactive users are end-dated, assessing which modules are being used, and verifying that all customizations (such as custom views) align with the licensed scope.
How can organizations avoid over-licensing with Siebel?
To avoid over-licensing, it’s crucial to regularly audit the actual number of active users and their access needs. Deactivating users who no longer need access, mapping roles appropriately, and ensuring licensing is matched to actual usage can help minimize unnecessary costs.
Why is it important to restrict access to Siebel modules?
Restricting access ensures that users interact only with the modules for which the organization has licenses. Organizations can avoid compliance violations and unexpected licensing fees by limiting permissions to relevant modules.
How do Processor licenses compare with User-based licenses in terms of scalability?
Processor licenses are often more scalable when the user count is expected to grow significantly or fluctuate. Unlike user-based licenses that require individual assignments, processor licenses are tied to the hardware capacity, making them suitable for dynamic environments.
What should Siebel administrators know about licensing?
Siebel administrators should know the licensing terms for each module, understand which modules the organization licenses, and recognize the compliance implications of granting access. Proper training and awareness are essential to avoid accidental compliance violations.
What are some common pitfalls in managing Siebel licenses?
Common pitfalls include over-licensing due to inactive users not being deactivated, under-licensing by granting access to unpurchased modules, and inadequate management of custom views that may use unlicensed functionalities. Regular audits and proper documentation are crucial for managing these risks.
Can Siebel licenses be adjusted as business needs change?
Yes, licenses can be adjusted depending on the license model. The Siebel Custom Application Bundle allows you to add or remove specific modules based on business requirements, offering flexibility and cost control as your organization’s needs evolve.
Read more about our Oracle License Management Services.
