About Request Management
This description is divided into following sections:
- What is Request Management?
- Concepts
- Request handling
- Price handling
- Site handling
- Location handling
- Status handling
- Access handling
- SLA handling
- Edit Scope
- Applicability
- Predefined execution can be defined using standard tasks in the Standard Task library.
- Dependencies can be created between connected standard tasks and Work stage also can be modified.
- A Description of the task to be performed.
- A Duration, specified in hours.
- An Activity Type.
- A Work Stage.
- Work Steps, a simple checklist of things to be done.
- Resource requirements, used to find eligible resources. It is possible to associate skills to a resource demand to further refine the requirement.
- Material/Part requirements.
What is Request Management?
The Request Management process is used to manage the lifecycle of Service
Requests received from customers. The core process has four main phases:
1. Request initiation
2. Dispatch
3. Execution & Reporting
4. Invoicing & Closure
There are also several administrative and supporting processes related to the core process, such as the Service Catalog, Request Contracts, Resource Monitoring, etc.
Concepts
Request
The Request has a number of related entities that are used during the
service lifecycle:
Request: The Request exists throughout the end-to-end flow of the Service Process. A Request can be initiated from different sources (e.g. manually, via a recurring service, integration etc.) and by different persons (roles) such as call center agents or a technician, who is at a customer's site and creates a request on behalf of the customer.
Request Scope: This defines the scope of a Request. A scope contains the Service and the Reported Item, which can be an Equipment Object or a Model, contract information, pricing, SLA details, Location and Address.
Request Work Tasks define the execution of the Request Scopes and describe the work to be done. The Work Tasks inherit their details from the Standard Tasks defined in the Service Catalog. A Request Work Task contains Resource Demands with skill requirements, material demands and other demands. When a Request Work Task is dispatched/assigned, a Request Work Assignment is created and handled by technicians.
Request Work Assignments: The dispatch process creates Request Work Assignments for resources. The actual execution is done through the assignments. The assignments update the Request Work Task with execution transactions and details, such as cost and sales information, time reports and reporting.
Sales Lines: Sales Lines are used to create the invoicing via the Request. Sales lines are created when reporting transactions, but it is also possible to manually create Sales Lines. In Request Management, 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
The Service Catalog is a collection of services provided to customers. A Service can be defined as a Service group or Service item to arrange the services as a structure for administrative purposes. A Service contains a description of the service as well as
Standard Tasks: Which is a predefined execution package, that describes how to execute the service.
Price Rules: Pricing rules control how to price the Service.
SLA Template: The SLAs applicable for the service. The SLA Template can create one or many SLA Commitments on a Request, Request Scope and/or Request Work Task.
Service Organization: Which is used to describe organization offers the service.
The Standard Task library contains the predefined execution packages.
Standard Tasks act as templates for what becomes a work task.
A Standard
task contains:
Service Organization
A Service Organization exists inside a company and is the owner of the Requests, Request Contracts, and Request Quotations. The Service Organization offers services defined in the Service Catalog.
Each Service Organization must be created with a default Work Owning Site, a Logistics Site and a Sales Site:
- Work Owning Site: the default owning site governs the Request Work Task Site of the Request.
- Logistics Site: the default logistics site governs the Part Site of the Request (unless an Alternative Logistic Site is defined on the Service Delivery Unit).
- Sales Site: the default Sales site governs the Sales part site of the Request.
There should be one or many Service Delivery Units defined on the Service Organization to handle the delivery of Request Work Tasks resulting from a Request.
Service Delivery Unit
When a Site is connected to a Service Organization it is referred to as a Service Delivery Unit. A Service Delivery Unit is responsible for the execution of Work Tasks resulting from the Request. Multiple Service Delivery Units can be connected to a Service Organization and one Service Delivery Unit can be defined as the Default Service Delivery Unit, which acts as the Maintenance Organization Site during work task creation.
A Service Delivery Unit can also have an Alternative Logistic Site for a Service Organization. If an Alternative Logistics Site is connected, the part site for a request will be determined by the Alternative Logistics Site defined on the Service Delivery Unit and not on the Service Organization.
During the work task creation, the Default Service Delivery Unit acts as the Maintenance Organization.
Sites connected as Service Delivery Units can only be used by a single Service Organization.
Service User Groups
Viewing a Request and its' related entities is controlled via the Service User Groups.
Request Handling
Requests can be initiated manually or via a Recurring
Service Program (the Source on the Request will be set to either
Manual or Recurring Service Program). During the initiation, a Service from
the Service Catalog and service item can be selected along with other information.
A request scope is created for each service added to the request. During the
request creation, request work tasks are automatically created, with the dependencies
based on the setup of the service item in the Service catalog.
- If the Request Scope is not covered by a contract line, the Request Work Task Price Rule information, and the SLA information is fetched to the Request Scope based on the Service Catalog setup.
- If the Request Scope is covered by a Contract, the Request Work Tasks are created based on the Service Catalog setup whereas the Price rule and the SLA comes from the contract line.
- If there is a Warranty applied on the Request Scope, the Request Work Tasks are created based on the Service Catalog setup, whereas the Price rule and the SLA is fetched from the Warranty. If the SLA is not defined on the Warranty, then the SLA will be fetched from the Service Catalog item. Since Request Work Tasks are automatically created based on the Service Catalog setup, manual preparation is normally not required, however it is possible to add additional Request Work Tasks to a scope.
The main goal of the Dispatch step is to optimize the usage of resources, and to make sure that SLA commitments can be met. There are multiple options for scheduling:
- Manually assigning work through the Assign dialogue
- The Dispatch Console which allows a dispatcher to schedule tasks one by one, either manually or assisted (by filtering resources based on skills and location).
- IFS Clouds Advanced Scheduling and Optimization component, PSO, used to automatically schedule all relevant tasks. In all cases, the Request Work Task status needs to be Released, which is achieved by releasing the Request. Once assigned, Request Work Assignments are created.
When the Request Work Task has been allocated to a resource, Transfer to Mobile needs to be executed (either using the button or a database job). This will send a push notification to the technician and make the Work Task available in the Mobile Client. Mobile execution is described in more detail in About Mobile Work Order.
Once the assignment is set to Completed, the work task status is updated to Work Done. When not using assignments, the task status can be updated directly. Sales and cost lines can be reviewed on the Request. The Invoicing button on the Request Cost and Sales page allows the creation of an Invoice Preview, either grouped by Request or by individual scope. Once the Invoice Preview is Approved, an invoice is created.
Status Handling
Each entity has its own status logic, with some automation between them. The available status per entity described 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:
- Releasing a Request or a Request Scope triggers the following:
Request Scopes are released
Request Work Tasks are
released
Material Orders are released
Purchase Requisitions are created
Actual Fixed Price sales lines are created
- Start Work Assignments:
Request Work Tasks are started
Request Scopes are
started
Requests are started
- Complete Work Assignments:
Sets the Request Work Task status to Work Done
if it is the last assignment on the task
Request Scopes are completed
The Request is completed
- Adding Request Scope to a completed Request:
Sets the Request status to Completed from Closed
- Adding a Request Work Task to a completed Request Scope:
Sets the Request status to Completed from Closed
- Closing a Request:
Closes the Request Scope
Finishes Request Work Tasks
- Reopen a Closed Request:
Sets the Request status to Completed from Closed
- Reopen a Closed Request Scope:
Sets the Request Scope status to Completed
from Closed
Sets the Request status to Completed
from Closed
- Reopen a Finished Request Work Task:
Sets the Request Work Task status to Work Done
from Finished
Sets the Request Scope status to Completed
from Closed
Sets the Request status to Completed
from Closed
Price Handling
Price Rule:
A Price Rule can be setup as basic data and can have multiple rule lines defined for different Sales Groups, Cost Types and if not both, a default line for All other. The rules can be connected to services in the Service Catalog, for generic pricing, and Contract for special pricing for the customer.
It is possible to use a toggle to create a "Quick Setup for the Total Scope". When the quick setup option is Free of Charge, a price rule line appears with a value of 0 for the revenue percentage. When option Fixed Price is used, a price rule line appears with 0 for the revenue percentage, but requires 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 is 100, to indicate that the total usage cost will be charged.
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 based on 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/Request Scope:
- Request Scope is self-sustained with its price rule details. (i.e. rule lines are saved on the scope).
- Price rule information is fetched via 1) Warranty 2) Contract 3) Service 4) default price rule line for All other will be saved (to charge all sales based on resource used with 100% revenue). If the Contract or Service has urgency based pricing, the price will be set based on Request Scope Urgency.
Fixed Price:
- Fixed prices are always defined on the Request Scope level (Both Planning and Actuals can be handled separately).
- Fixed Price lines can be created automatically based on price rule lines which are defined 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 Request Work Task.
- They are mainly defined via the planning and created by transactions reported.
Evaluation Criteria:
To pick the correct rule line, the Sales/planning line is first evaluated for a sales parts Sales Group and then the Cost type. If there is no price rule line defined for above criteria, 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 the table above. 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 important to setup sales parts to be fetched automatically to the planning lines on the work tasks. To ensure that happens, the resources and the materials that are required during the work task flow, need to be connected to sales parts in the relevant Service Delivery Units. 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 Organization is connected to default Sites that define the Work Owning, Logistic and Sales sites applicable to Requests.
To handle the sales, the site set as Default Sales Site on the Service Organization is saved at the Request level. The Sales Site is then inherited to the Request Scope and the Sales Site should always be same as the Sales Site on the Request. It is currently not allowed to change the Sales Site manually.
During the automatic Request Work Task creation, the Default Owning Site of the Service Organization is set as the Request Work Task Site and the Default Service Delivery Unit and Delivery Unit are set as the Maintenance Organization Site and Maintenance Organization respectively. If a Work Task is manually created, the Work Task Site and the Maintenance Organization Site should be a Site that is allowed for the user.
Location Handling
During Request Initiation and the creation of a Recurring Scope, the Location can be defined using the following options:
- Existing Location
- New Location
- One-off Address
During the initiation of a Request and Request Scope, if the selected object is associated with a Location, that Location and Address will be automatically fetched and displayed in the Location and Address fields. It is possible to override the fetched Location by selecting one of the options mentioned above.
The location can be edited at the Request level before the Request is completed, and any updates to the Location can be reflected in the associated Request Scopes and Request Work Tasks. The location can be edited at the Request Scope level before the Request Scope is completed, and any changes made can update the Request Work Tasks connected to the respective Request Scope.
At the Request Work Task level, the Location can also be edited, and if necessary, it is possible to define an End Location for the Request Work Task. An end location may be useful if a job starts at one powerline tower and ends at another for example. It is important to note that a Start Location must be defined for the Work Task before an End Location can be set and Allow Multiple Visits must be disabled, since it is undefined where the resource will be when splits occur.
Access Handling
In the Request process, the access control is handled on Request level, Work Task level and Sales level.
Creation of Request:
Creation of the Request is not restricted, and any user can create a Request and view the created Request (For example, a B2B customer technicians also can log a request), however the user must have access to the Site related to the Service Organization Service Delivery Unit.
Handling Request:
To further view and handle Requests, 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:
In Dispatching and Execution where Request Work Tasks are handled, the Work Task Site must be registered as a User Allowed Site for the user handling them.
SLA Handling
SLA Commitment
An SLA Commitment can be defined either as a commitment between two parties, for example a service provider and a customer, or as an internal commitment. The SLA Commitment can be set up to either have its due date calculated from a fixed start date, the due date to be on a specific deadline, or to be event driven in the sense that an event can trigger a starting criterion for the SLA Commitment and another event to fulfill it. Multiple SLA Commitments can be created for the same Request, Request Scope, and Request Work Task and the same event can fulfill one SLA Commitment and trigger the start of another. It is also possible to create multiple SLA Commitments with the same start- and fulfillment events with the duration set differently, where for example, one is committed to a customer, and another one is used for scheduling.
Edit Scope
A Request Scope may have to be modified due to various reasons such as mistakes during Request logging, wrong information received from the customer, technician identifying a difference during execution which affects the scope etc. Special handling of scope change is required since editing the Service, Service Item, Contract and Location affects many other underlying flows. When these attributes are updated, the original Request Scope will be cancelled and a new copy of the original Request Scope will be created, with the new details entered.
Edit Service/ Reported Item
For Requests created manually (not via a Recurring Service Program) the Service, Reported Item (Object or Model), Location and Address can be edited if the Request Scope is in status New, Released or Started. Once modified the existing Scope gets cancelled and a new Scope gets created with edited information. If the Work Tasks connected to the existing Scope can be automatically cancelled, then those tasks will get cancelled automatically once the Scope is edited. But if the Work Tasks connected to the existing Scope have transactions, they 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.
Reopen Work
Reopen Request
A closed Request can be reopened. By doing so, the status of the Request will be changed to Completed. Requests can be reopened if additional Request Scopes are to be added to the Request.
Reopen Request Scope
A closed Request Scope can be reopened again. By doing so, the status of the Request Scope will be changed to Completed. If this action is performed while the Request is closed, the status of it will also be changed to Completed.
Request Scopes can be reopened if, for example, additional Request Work Tasks or Planned/Actual Fixed Price Lines are to be added the Request Scope.
Reopen Request Work Task
A Finished Request Work Task can be reopened. By doing so, the status of the Request Work Task will be changed to Work Done. If this action is performed while the Request Scope and the Request are Closed, the status of them will be changed to Completed.
Request Work Tasks can be reopened if, e.g. additional transactions, sales lines or materials has been missed during the closure of the Request Work Task and has to be added.
Applicability
Applicability on Service
Services defined in the service catalog are normally globally applicable, for any type of asset. However, if the service is not applicable for all types of assets, Asset Applicability can be defined on the service. By defining applicability sets, using one or a combination of two grouping criteria used to group assets, the service will only be applicable be applicable for requests created for those objects and models. For Assets defined as Service Objects, the available grouping criteria are Manufacturer, Object Type and Category. For Model assets, the only available grouping criteria is Object Type.
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 are normally globally applicable, for any type of asset. However, if Standard Task is not offered for all services and for all types of assets in the service execution, Applicability can be defined on the Standard Task connected to the Service. By defining applicability sets, using one or a combination of two grouping criteria used to group assets, the Standard Task will only be applicable for requests created for those objects and models.
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, Skills, Certificates and Competencies) in Standard Task are normally globally applicable, for any type of asset. However, if Standard Task requirement are not suitable for all for all types of assets, specific asset applicability can be defined on the Standard Task requirements.
Work Steps, Materials, Resources, Skills, Competency and Certificates will be created using filtered records according to grouping criteria in Standard Task and Service Item/ Product.