Oracle Siebel CRM is a customer relationship management suite known for its modular approach and industry-specific solutions. Siebel’s licensing involves a combination of user-based licenses (with multiple user types) and sometimes processor-based licensing for certain scenarios. Additionally, Siebel environments include various components (like servers, databases, and integration tools) with their licensing considerations. In this section, we discuss Siebel’s Named User and module-based licensing, how external (customer/partner) users are handled, and what “server-side” licenses (like database and middleware) come into play.
User Licensing in Siebel: Named Users and More
Siebel CRM offers several types of user licenses:
- Named User Plus (NUP): This is similar to a standard named user – each individual accessing Siebel requires a license. Siebel uses the Oracle “Named User Plus” definition, which includes not only human users but also any non-human devices or scripts that log in. NUP is the metric Oracle often uses for internal employees or contractors using Siebel.
- Application User: In Siebel context, an Application User license often refers to a license for a specific Siebel module or application. For example, Siebel might require at least one Base CRM Application User per user, plus additional licenses if you enable an industry-specific module (like Siebel Automotive or Siebel Financial Services). In practice, the difference between NUP and Application User can be subtle – Siebel’s price list shows a Base Application (Application User metric) that every user must have, and then possibly module add-ons. Essentially each user may need a “Siebel CRM Base” license and then any applicable add-on module licenses.
- Concurrent User: Historically, Siebel (before Oracle acquisition) had concurrent user licensing for some external or employee use cases. Oracle has since retired concurrent user licensing for Siebel – new Siebel licenses are sold as named user or processor only. If you have an old contract with concurrent Siebel users, note that Oracle will expect you to transition eventually. In audits, they may count the maximum named users that could use those concurrent licenses.
- Employee User vs Partner/User: Siebel distinguishes internal users vs external partner/customer users. Oracle offers a Registered User metric for external (non-employee) users like business partners or customers accessing Siebel portals. A Registered User is essentially a named user for external audiences, often priced lower per user but requires they are not your employees. This is important: external users cannot simply use an internal license; they need the appropriate external user license or you must license by processor for external use.
Module/Component Licensing: Siebel is highly modular – Sales, Service, Marketing, Call Center, etc., and industry vertical modules. Typically:
- You must license at least one Siebel Base CRM module for each user. Then, if you use industry-specific functionality, you add the relevant industry base option for each user. For example, if you’re in financial services and use the Siebel Financial Services module, each user would need both “Siebel CRM Base” and “Financial Services Base Option” licenses. Oracle’s price list explicitly lists these base options, meaning users are counted per module.
- Some Siebel add-ons (like Siebel Configurator, Siebel Tools for developers, etc.) might have separate licensing. For instance, Siebel Tools might be licensed per developer user, or Siebel Integration modules might have a per Application User metric.
- Example: A Siebel Sales implementation in the Telecom industry: each sales user might need “Siebel CRM Base – Application User” and “Siebel Communications Base Option – Application User”. These would be stacked for the same user. If you have 100 sales reps, that’s 100 of each license.
Enterprise License: Oracle also mentions an Enterprise metric for Siebel in some contexts. This typically refers to an Unlimited License Agreement (ULA) or enterprise license covering Siebel for a fixed fee, allowing unlimited users to use it within a certain scope. Sometimes big customers negotiate a Siebel enterprise license so they do not worry about per-user counts. Also, Siebel can be part of a larger Oracle enterprise license (like included in an ELA with other products). If you have such a license, ensure you understand which Siebel modules are included and for what population (often, enterprise licenses still differentiate internal vs external usage).
Processor-Based Licensing for Siebel
Oracle allows Siebel to be licensed by Processor as well, though this is less common except in scenarios with large external user bases:
- If your Siebel implementation is customer-facing (e.g., a Siebel eService web portal for millions of customers), counting users is impractical. In such cases, you can license the Siebel software by the number of server processors it runs on, with unlimited users. This uses the same core factor method: count cores × core factor = processors needed for Siebel. You would then not need individual user licenses.
- Often, Oracle might license certain Siebel components (like Siebel Web Server or Siebel Object Manager instances) by processor if they serve public users. For example, Siebel Customer Portal might be licensed per CPU to cover all customers logging in.
- Oracle’s price list shows components like Oracle Application Management Suite for Siebel, which has both Named User and Processor options. This refers to management tools, but it illustrates that Siebel’s runtime could similarly be licensed.
Consider that if you use Processor licensing for Siebel, you may still need at least one named user license for administrative access (Oracle sometimes requires at least one named user even when processors cover unlimited use, for admin). Check your contract specifics.
External Users and Integration Considerations
As mentioned, external users (customers, partners) accessing Siebel require licensing:
- Registered User licenses: If you have a partner portal via Siebel (Siebel PRM) or a customer self-service site, Oracle has the “Registered User” metric, a discounted Named User for external users. Only non-employees qualify, and you typically license them in bundles. For instance, you might license 1,000 Registered Users for your customer portal. If you exceed that (more customers register), you buy more. Oracle will check that no employees are misclassified as registered external users (that’s a compliance no-no).
- Concurrent External User (legacy): Old Siebel had concurrent session licensing for eService. Oracle now would just do CPU licensing or Registered User. If you have something like “200 concurrent external user” license from pre-Oracle days, clarify with Oracle how to remain compliant as concurrency is hard to measure in web contexts now.
- Multiplexing: If many external users access Siebel through a single integration point, Oracle’s multiplexing rule applies – you still need to license all end-users. For example, if a thousand customers access Siebel data through a single portal account, Oracle would demand licensing for those 1000 (this would be discovered, perhaps via logs of unique accesses). It’s safer to give each external user a unique account (then count them properly) or use CPU licensing to avoid the issue.
Integration & Server-side needs:
- Database License: Siebel requires a database to store its data (usually Oracle Database, but could be SQL Server/DB2). Oracle often includes a restricted-use Oracle Database license with Siebel for its repository. That means if you use Oracle Database for Siebel’s data, you might not need to buy a DB license separately, provided the database is only used for Siebel. Like EBS/PeopleSoft, Oracle’s policy is that the Siebel license covers an Oracle DB to host Siebel schemas. You’d need a full DB license if you use that DB for additional custom schemas outside Siebel.
- Middleware/Server components: Siebel runs on its application servers (the Siebel Server, a C++ based component, and a web server plugin). It does not require WebLogic for core functionality (Siebel has its own object manager and typically uses Oracle HTTP Server or Microsoft IIS as the web container). However, certain Siebel optional components do involve other Oracle middleware:
- Oracle Policy Automation (OPA): Some Siebel industry solutions integrate with Oracle Policy Automation. Oracle’s licensing info states, e.g., “A license to Siebel Warranty includes restricted-use licenses for Oracle Policy Automation and the OPA Connector for Siebel”. So if you use the Siebel Warranty module, you can use OPA specifically for that purpose without extra cost. If you tried to use OPA beyond Siebel (say, for other decision automation), that would violate the restriction.
- Siebel Enterprise Integration Manager or Analytics: If you use Siebel with Oracle Analytics, you might need BI licenses separately, but Siebel itself had a component called Siebel Analytics (which evolved into OBIEE). Nowadays that’s separate (Oracle BI is separate license).
- Siebel Tools: These are used by developers to configure Siebel. The price list shows Siebel Tools priced per Application User (likely per developer). Many times, Oracle includes a couple of Siebel Tools licenses with the purchase, but officially, each developer customizing Siebel might need a license. Check if your Siebel bundle included Tools for free or not.
Server/CPU needs vs user needs: Ensure that if you have licensed users, you still account for any non-user-based components:
- For instance, if you run a Siebel Marketing Campaign feature that sends outbound emails, some Oracle products like Oracle Marketing Segmentation Server might come into play (older Siebel marketing analytics). Oracle could consider that part of Siebel or an add-on.
- If you integrate Siebel with an Oracle SOA Suite or other middleware, that middleware must be licensed separately (the Siebel license won’t cover Oracle SOA). Many Siebel deployments integrate with an Oracle database, which is covered by restricted use, and may use Oracle Identity Manager for SSO (that would need a separate license unless included via a suite).
- In summary, License all human users (or CPUs) for Siebel itself, and don’t forget any external integration components (database, OPA, etc.)—most are included in a restricted fashion, but anything outside Siebel’s scope needs its own license.
Recommendations
- Count All Types of Users: List internal users who use Siebel (sales reps, support agents, etc.) and ensure you have Named User Plus licenses for each. Separately, list external users (partners, customers) who log into Siebel portals or are managed in Siebel. Decide whether to license them via the Registered User metric or by covering the external-facing Siebel modules with processor licenses. For a large customer base, processor licensing may be simpler; you might count and license by user for a defined community of partners.
- Base vs Add-on Modules: Check Oracle’s price list to verify which Siebel modules you use and their required licenses. Typically, every Siebel user needs the Base CRM license. On top of that, if you’ve enabled an industry vertical, all those users need the industry base option license. And if you use specialized modules (like Siebel Call Center, Siebel Email Response), there might be separate line items. Make sure you have those covered. It’s common in audits for Oracle to find a customer using Siebel Marketing without having purchased that component specifically.
- Don’t Mix Internal and External User Licenses: Ensure your employees are only counted under the proper (usually more expensive) licenses, not miscategorized as partner or external. Oracle will scrutinize user lists for email domains or roles; if an account labeled a partner is an employee, that’s a compliance issue. Maintain clear separation. If employees and partners use the same Siebel application, you’ll need to license employees with standard Siebel user licenses and partners with partner user or CPU licenses in tandem.
- Monitor Usage and Modules Enabled: Siebel systems can enable many modules, even if you don’t use them all. Use Siebel’s license usage utilities or simply audit what functionalities you have turned on. For example, inadvertently allowing some users into a Siebel module you didn’t license is a problem. Siebel doesn’t have a license key system for modules; it’s honor-based. So, if you haven’t licensed Siebel Marketing, ensure no one in the system is assigned to marketing screens. Configure responsibilities accordingly and possibly “hide” or turn off modules you didn’t buy.
- Leverage Restricted-Use Entitlements: Remember that with Siebel, you likely have the right to use an Oracle Database to support it. Ensure your DBAs understand that the database is licensed only for Siebel data. Similarly, know that you have rights to the Siebel Web Server component, etc., so you shouldn’t be separately charged. If an Oracle auditor queries your lack of DB license on the Siebel DB server, be prepared to show the Siebel contract clause about the included DB license. Keep that documentation handy to avoid any confusion.
- Watch Integration Points: If you integrate Siebel with other Oracle products (like Oracle Integration Cloud or SOA to connect Siebel to ERP), those other products need their licenses. Siebel’s license won’t cover middleware. One common oversight is using Oracle Analytics against Siebel data, which requires Oracle BI licenses (unless you have a ULA covering both). Make sure all surrounding systems are properly licensed.
- Review Industry Solutions for Bundled Components: Some Siebel industry solutions (like Siebel Insurance, Siebel Public Sector) bundle third-party or Oracle components. For instance, Siebel Public Sector utilizes Oracle Policy Automation (OPA) to determine eligibility. Oracle has allowed Siebel Public Sector customers to use OPA in that context without a separate purchase. But you must not use that OPA for non-Siebel purposes. Document these allowances and stick to their scope. If you deploy OPA or other integrated tools, use them only as extensions of Siebel workflows.
- Plan for Growth (or Reduction): If your number of Siebel users (internal or external) is expected to grow significantly, plan the licensing costs. It might be worth moving to a processor model at a certain breakpoint. For instance, if you currently have 500 external users and might expand to 5,000, calculate the cost of just licensing a couple of server CPUs versus 5,000 user licenses. Oracle’s core factor might make two processor licenses relatively affordable compared to thousands of users. Conversely, if your user base shrinks, see if you can reallocate those licenses, or if you’re in a ULA, you might not benefit from the reduction until renewal.
- Keep User Lists Clean: As with any user-based licensing, remove Siebel user accounts that are no longer needed. Particularly for Siebel, which often has high license costs per user, you don’t want to be licensing ex-employees or inactive partner logins. Periodically audit Siebel user records and inactivate anyone who shouldn’t have access. In an Oracle audit, they may ask for an extract of user tables – make sure that it won’t include hundreds of dormant accounts that inflate your required count.
- Engage Oracle for Clarification When Needed: Siebel licensing has many nuances (base vs industry vs add-on, etc.). Don’t hesitate to get official clarification from Oracle on how a certain module is licensed. For example, “If I use Siebel Customer Portal for 20,000 customers, is it better to do 20k Registered Users or x processors? What’s recommended and what are the costs?” Getting this in writing (or via an official quote) can guide you and also serve as evidence of your intent to comply in the agreed way.
In summary, Siebel CRM licensing requires carefully accounting all user types (internal, external, partners) and ensuring each has the appropriate license category. With Oracle’s current model, most Siebel deployments will mix Named User Plus for employees with either Named or Processor for external communities. By aligning your license counts with actual usage and keeping track of the included (restricted-use) infrastructure licenses, you can stay compliant and avoid surprises from Siebel audits.
