Request Management
This description is divided into following sections:
- What is Request Management?
- Concepts
- Request handling
- Price handling
- Site handling
- Status handling
- Access handling
- SLA handling
- Modify Scope
- Applicability
- Predefined execution can be defined using standard tasks in the Standard Task library.
- Dependencies can be created among connected standard tasks and Work stage also can be modified.
- Work Type
- Work Stage
- Work Steps
- Resource requirement with special competency and certificate
- Material/Part requirements
What is Request Management?
The Request Management is mainly about the process of handling
service requests received from the customers. The process mainly
contains four phases:
1.Request initiation
2.Dispatch
3.Execution & Reporting
4.Invoicing & Closure
It is also supported by many administration setups and support processes such as Service Catalog, Request Contract, Resource Monitoring, etc.
Concepts
Request
Request is connected to many other entities during the lifecycle of the
request process:
Request: Request exists throughout the end to end flow of the service process. Request can be initiated from different sources and by different persons(roles) such as Call center agent, Technician who is in the customer’s site and create a request on behalf of the customer etc. Request also could be handled globally in this context
Request Scope: This defines the scopes of the request. Scope contains the Service and the Reported Item of Object, Model, or Part. Contract, pricing and SLA are also applied on the scope.
Work Task: Execution work of the service is mainly done via the work tasks and in the service process it is mainly created automatically during the request logging. It contains skills, part and other demands. Then it involves in the dispatching phase where the assignment is created and handled by technicians
Work Assignments: Dispatch process creates work assignments for resources. Execution is mainly done by work assignments.
Sales Lines: Sales Lines are used to create the invoicing via the request. Sales lines are mainly created when reporting transactions but it is also possible to manually create sales. In request, the sales are always handled via the sales site defined on the service organization. Sales are used for invoicing and the billing agent is the main role who handle the sales.
Service Catalog
Service catalog is a concept to maintain a list of services offered by the service provider. Service can be defined as a ‘Service group’ or ‘Service item’ to arrange the services as a structure for administration purpose. Service contains:
Standard Tasks: Predefined execution (how to execute the service)
Price Rule: Pricing (How to price the Service)
Request SLA Template: SLA offering for the service
Service Organization: Which organization offer the service
A list of standard tasks where a standard task is template of a work
task.
Standard task contains:
Service Organization
A service organization exists inside a company and is the owner of the requests, contracts, and service quotations and offers services defined in the service catalog.
Each service organization must be created with a default Owning Site, Logistics Site, and a Sales Site:
- Work Owning Site: the default owning site governs the Work Task Site of the request.
- Logistics Site: the default logistics site governs the Part Site of the request (unless a Alternative Logisitc Site is defined on the branch).
- Sales Site: the default Sales site governs the Sales part site of the request.
There should be one or many branches defined on the service organization to handle the delivery of work tasks resulting from a Request.
Branch
When a Site is connected to a service organization it is referred to as a branch. A branch is responsible for the execution of work tasks resulting from the Request. Multiple branches can be connected to a service organisation and one branch can be defined as the default delivery branch which acts as the maint org site during work task creation.
A branch can also be connected as an alternative Logisitcs site for a service organization. If connected, the part site for a request will be determined by the alternative Logisitcs site defined on the branch and not on the service organisation.
During the work task creation the default delivery branch acts as the maintenance organization.
Sites connected as branches can be used by a single service organization only.
Service User Groups
Viewing a request is controlled via the service user group.
Request Handling
Request can be initiated manually or via a recurring
service program. During the initiation, a service from the service catalog and
service item can be selected along with other information. Request scope is
created for each service added to the request. During the request creation,
work tasks are automatically created with the dependencies based on the setup
of the service item in the Service catalog.
If the scope is not covered
by a contract line, then the work tasks, then price rule information and the
SLA information is fetched to the scope based on the service catalog setup.
If the scope is covered by a contract, then the work tasks are created based on the service catalog setup and Price rule and the SLA offering is fetched from the contract line.
Since the work tasks are automatically created based on the service catalog setup, the manual preparation is not required. However, manually preparation can be done adding work tasks to the scope if required.
Works Tasks can be allocated manually or via PSO. To allocate, work task should be in released status. Work assignment are created during the dispatch process. Refer AboutPSO.
Execution is done mainly via the mobile.
The sales lines generated are invoice via the request.
Status Handling
Basic statuses of the request and it’s connected entities are as below,
| Request | Request Scope | Work Task | Work Assignments |
| New | New | New | Assigned |
| Released | Released | Released | Accepted |
| Started | Started | Work Started | On-Route |
| Completed | Completed | Work Done | Waiting at Location |
| Closed | Closed | Finished | Work Started |
| Cancelled | Cancelled | Cancelled | Pending Completion |
| Completed | |||
| Incompleted | |||
| Cancelled |
Some status change actions drive the business process and changes the statuses of other entities as below
- Release Request or Release Scope Action does below:
Release Scope
Release Work tasks
Release Material
Orders
Create PRs
Actual Fixed Price sales lines are created
- Start Work assignments:
Start Work Task
Start Request Scope
Start Request
- Complete Work Assignments:
Set Work Task work done
Complete Request Scope
Complete Request
- Close Request:
Close Request Scope
Finish Work Tasks
Price Handling
Price Rule:
Price rule can setup as a basic data. It can have multiple rule lines defined for different Sales Groups, Cost Types and if not both, a default line for All other. Then the rule can be connected to the service in the service catalog (for generic pricing) and Contract for (special pricing for the customer).
When the quick setup option is Free of Charge, a price rule line appears with a value of 0 for the revenue percentage. When it’s a Fixed Price, a price rule line appears with again 0 for the revenue percentage, but require a sales part to be defined, where the price defined in the sales part is fetched as the fixed price, when the price rule is applied. When the quick setup option is Usage Based, the revenue percentage will become 100, to indicate that the total usage cost will be charged from the customer.
If a quick setup is not adequate for defining specific price rule lines, the normal setup can be used. There are three types of price rule lines that can be defined through the normal setup; Sales Group, Cost Type and All Other. The Sales Group type price rule lines require a sales group to be defined with a percentage of revenue. The Cost Type price rule lines requires specifying a cost type, which can either be, Personnel, Material, External, Expenses and Tool/Equipment. Sales for cost types are defined on the work task level and it is created due to reported transactions. The All Other type price rule line is the default, single and compulsory price rule line covering all other prices, that are not covered through any other specific price rule line.
Price Rule on Request/Scope:
- Scope is self-sustained with its price rule details. (i.e. rule lines are saved on the scope).
- Price rule information's are fetched via 1) Contract 2) Service 3) can be defined manually, if not 4) default price rule line for All other will be saved (to charge all sales with 100% revenue)
Fixed Price:
- Fixed prices are always defined on Scope level (Both Planning and Actuals can be handled separately)
- It is mainly created automatically due to a price rule lines which are set as “include in fixed price”
- It is also possible to create manual fixed prices if required.
Other Sales:
- Sales (planning & actual) for other cost types are always connected to the work task.
- They are mainly defined via the planning and due to transactions reported
Evaluation Criteria:
To pick the correct rule line, the Sales/planning line is first evaluated for sales part’s “Sales Group” and then the “Cost type”. If there is no price rule line defined for above criteria's, the default rule line defined for “All Other’ is considered
Application of Rule:
Rules on rule lines are applied on planning and sales
as per in the above table. Basically, the fixed prices are automatically created
due to price rule lines which are defined as ‘Include fixed prices.
For
other sales (planning and actual) the revenue% and markup is set as per the
rule. The sales price (in cost based scenario) and the sales amount is calculated
considering the markup% and revenue %.
In order for the usage-based price rule lines to work smoothly, it is convenient to setup the sales parts to be fetched automatically to the planning lines on the work tasks. For that, the resources and the materials that are required during the work task flow, needs to be connected to sales parts in the relevant branches. It is also possible to manually define the sales parts in planning or sales lines in the work tasks.
| Rule on Price Rule line | Applicability for Fixed Price | Applicability for Other Sales (Planning and Actual) |
| 1. Include in Fixed Price | Fixed Price line is created with defined sales part | Sales is not considered for revenue [Revenue % is set as zero] |
| 2. Cost based with markup % | N/A | Sales price is calculated based
on Cost [Sales price = Cost ( Markup % + 1 )] |
| 3. Revenue % | N/A | Sales in based on the defined
revenue |
Price Logic:
When fetching the sales prices and discounts, the price logic is applied considering agreements, price lists etc.
Site Handling
During the Request logging, the service organization is set as the owner of the request and each service organisation is connected to default Sites that define the Work Owning, Logitics, and Sales sites applicable to requests.
To handle the sales, the site set as default sales site on the service organisation is saved at request level. The sales site is then inherited to the scope and the sales site should always be same as the sales site on the request. (For now, Sales site is not allowed to change manually).
During the automatic work task creation, the default owning site of service organisation is set as the work task site and the default delivery branch and delivery unit are set as the Maint Org site and Maint Org of the task. If the work task is manually created, the WT site and the Maint Org site should be a site that are allowed for the logged in user.
Access Handling
In service process the access control is mainly handled on request level, work task level and sales level.
Creation of Request:
Creation of request is not restricted and any FND user can create a request and view the created request (For example, a B2B customer technicians also can log a request) i.e. they can create request for any service organization.
Handling Request:
However, to further view and handle request the user should be connected to the service organization (this is mainly for the contact agents, service managers, billing argents who view information on request level) Therefore the person who connected to the service organization can view the request owned by the organization
Handling Work Task:
Then in dispatching and execution where the work task is handled, the work task site should be registered as a user allowed site in-order to view and create work tasks (When automatic work task creation in logging this should be bypassed – not in 2020R1 release)
Handling Sales and Price information
SLA Handling
Service Level Package
Service levels that the service provider offer can be defined in Service level package. The Service level package indicates the respond and resolution time for each work stage in the package. It also indicates the scheduling parameters for each service level lines.
Request SLA Template
Service level packages can be connected to the Request SLA template and the templates can be offer via the Contract line, Service or Service Organization.
Modify Scope
Request scope might have to be modified due to various reasons such as, mistakes happened during request logging, wrong information received from the customer, technician during execution identifying a difference which affects the scope etc. Special handling of scope change is required since modifying the Service, Service Item, Contract effects many other underlying flows.
Modify Service/ Reported Item
Service, Reported Item (Object, Part, Model) or both can be modified if Request Scope is in status New, Released or Started status. Once modified the existing Scope gets cancelled and a new Scope gets created with modified information. If the Work Tasks connected to the existing Scope can be automatically cancelled, then those tasks would get cancelled automatically once Scope is modified. But if the Work Tasks connected to the existing Scope need a manual decision about how it should be handled then those Work Tasks will be moved to new Scope when the existing Scope is Modified. When cancelling the Work Tasks automatically, all underlying connections such as allocations, requisitions will also get cancelled. Sales lines of the moved Work Tasks will be updated with Price Rule applicable for the new Scope unless they have already been invoiced before moving. Actual Fixed Prices reported via a Price Rule will only move to new Scope if it has been considered for invoicing (invoice preview/invoice created) and Price Source 'Price Rule' is changed to 'Manual' before moving. However Manually reported Actual Fixed Prices will always move to new Scope. Highest status of the Work Tasks connected to the New Scope would be the status of the New Scope as well.
Modify Contract
Contract can be modified at any stage before closing the Request. Once Contract is modified Scope, Work Tasks and Pricing will also be modified accordingly.
Applicability
Applicability on Service
Services in the service catalog can be defined commonly for any type of asset. However, if service is not offered generally for all type of assets, then the specific asset applicability can be defined on the service by defining sets using one or combination of two grouping criteria’s used to group assets (for Asset defined as Equipment Objects, the available grouping criteria’s are Manufacture, Object type, Category).
In Request Initiation applicability will be automatically applied according to the defined grouping criteria in Service and Service Item/ Product connected to the Scope.
Applicability on Standard Tasks of Service
Standard Tasks connected to the service item can be defined commonly for any type of asset. However, if Standard Task is not offered for all services generally for all type of assets in the service execution, then the specific asset applicability can be defined on the Standard Task connection by defining sets using one or combination of two grouping criteria’s used to group assets.
In automatic task creation when initiating the Request, connected Standard Tasks will be filtered according to the defined grouping criteria in Standard Task connection and Service Item/ Product.
Applicability on Standard Task
Requirements (work steps, materials, resources, certificate and competency) in Standard Task can be defined commonly for any type of asset. However, if a Standard Task requirement is not suitable for all for all type of assets, then the specific asset applicability can be defined on the Standard Task requirement by defining sets using one or combination of two grouping criteria’s used to group assets.
Work Steps, Materials, Resources, Competency and Certificates will be created using filtered records according to grouping criteria in Standard Task and Service Item/ Product.