Service Management beyond IT – or is this too beyond?

farmer.png

Beyond IT

Service Management is not only used for IT requests but also for HR-, Procurement-, Facility- requests and so on.

This of course makes sense, because it structures requests and mitigates confusion. But how far does the beyond IT “hype” go?

Operations support – fresh food delivery

In one of our “beyond IT” projects we handle fresh food supplies from farmers via a delivery company to consumers.

This is easily done with the help of the automator’s end user wizards. The farmer simply organizes the food packages in 4me Self Service so that the delivery company can pick them up.

iframe - automator - wizard.gif

The workflow capabilities of 4me help to delivery the packages in an efficient and effective way.

Happy delivery!

man-in-a-party-dancing-with-people-3

k.konwalin@techwork.at

 

automator | Application extension

science (1).png

Business case

Data often need to be presented in a different form to become information. 4me for example, contains all required components to maintain budgets. There are products,  purchasing workflows, projects and invoices.

To manage financial data in a practical way the components can be presented in summarised form.

The automator

With the automator it is simple to pull data and present them effectively.

Budget_Monitor.png

Development time

We talk about a couple of hours to configure such a page…

 

man-in-a-party-dancing-with-people-3

k.konwalin@techwork.at

 

 

Test Driven package Development

The purpose

TDD (Test Driven Development) simplifies the process to generate well designed package code. It further eliminates the risk of package failures due to implementation changes nearly completely. The notion of Fail (red), Pass (green), Refactor increases code quality on a continuous basis.

TDD

The process

At first a test always fails, this means that your code does not implement the feature the test is about. Next you do just the minimum in order to pass the test. So the output of the test changes from red to green. Then you refactor the implementation package and the test should remain green.

TDD-error-success

Green is a good thing!

The added value

It often boils down to the following scenario. You develop a package, everything works fine for a long time. Then you like to change something. Changing implementation code is always risky. The TDD functionality reduces that risk to a minimum, meaning that you can act faster to implement changes and sleep better!

man-in-a-party-dancing-with-people-3

k.konwalin@techwork.at

Product sheet

Tired of closing records manually?

The situation

You are most likely familiar with the ITRP sandbox environment (…/itrp.qa). You configure and test new things there. At some point you want to train people with your specific configuration but over time the sandbox became messed up.

Many open test records like Requests, Changes, Tasks are open and need to be closed before a training starts to make it easier for the audience. The challenge you face is to close probably 100s of records manually.

Manually in the automator age?!? Not so much

You simply need to register a Change that triggers the automator package and you are done. After a couple of minutes your sandbox environment looks clean again and your audience does not get lost in test records.

clear-sandbox.png

The automator package – main function

The package is straight forward. It checks whether the above change is selected and started. Then it closes all changes and afterward all requests.

Hint: If a change is closed all linked tasks are closed automatically. That way there is no need to loop over open tasks.


(function() {
 if (!firePackage(PKG_SETTINGS.implementationTaskTemplateId,task.template.id, task.status)) return;
 log('automationTaskTemplateId: ', PKG_SETTINGS.implementationTaskTemplateId);
 log('task Template ID ', task.template.id);

 closeChanges();
 closeRequests();

}());
//Helper functions
...
}

Happy training!

man-in-a-party-dancing-with-people-3

k.konwalin@techwork.at

automator-logo

Reduce clicking to obtain information

Use case

Imagine you sit in front of the ITRP inbox. An implementation task has been assigned to you. The specific relevant information rests in the Request’s custom data field because a request template with an UI extension provided the structured input form.

Therefore, you need to click on the Request link of your task, to open the Request in a new tab (cmd + shift + click). The inefficient thing is that you need to work with 2 tabs,  you read specific information in one tab and you need to comment in a second tab.

ui

The automator solves this problem with a couple of lines of code

 

//This package copies "custom_data" from the request
//to all tasks, so that people do not need to click

const PKG_SETTINGS = {
 automTaskTemplateID: 139
};

(function main(){
 if (task.template.id !== PKG_SETTINGS.automTaskTemplateID) return;
 const chg = task.change;

 if (chg.requests.length === 0) return;
 const req = chg.requests.first();
 const reqCustomData = req.custom_data;

 for (let t of chg.tasks){
   let mergedCustomData = assign({}, reqCustomData, t.custom_data);
   update('tasks', t.id, {
     custom_data: mergedCustomData;
   });
 };
})();

Output

The automator package copies all UI extension data to all tasks if a certain Task Template is used. Therefore it works in a generic way. Independent of what you have in your Request UI extension. It always works!

Furthermore you can select what UI data you want to see in specific tasks. Simply put your field selection into the UI Extension and add the extension to your task template.

output

Now, you instantly know what you need to do, without clicking around. Makes sense, right?

man-in-a-party-dancing-with-people-3

k.konwalin@techwork.at

automator-logo

ITRP_reporting includes audit records

Product sheet

Many customers asked whether the automator is involved in our ITRP_reporting solution or not. No. We use our PowerShell framework to populate the SQL database. Right now, this is the most efficient and effective technology for that purpose.

Audit records

Audit records can not be exported by using the ITRP standard export functionality. Audit data need to be exported via the API. This is the newest capability of our reporting solution.

For what purpose do you need the audit records?

Examples:

  • How often have tickets changed assignments / Service Instances?
    • If your Service Desk follows a “Capture, structure, solve or assign (change the Service Instance in ITRP)” approach, it tells you how well the Service Desk performs in terms of narrow the issue down to the root cause, when they structure the ticket
  • How often has a ticket being touched?
    • Depending on detailed data this could be an indicator of working not efficient or people are simply not trying to solve the ticket in one go.

Easy to generate standard dashboards

Our PowerShell framework normalizes the database automatically, including the audit tables. Based on that easy to use structure it is easy to generate dashboards in PowerBI or another tool of your choice instantly.

ITRP_reporting_backlog

Product sheet

techwork-logo

k.konwalin@techwork.at

 

Stimulate experimentation

Companies increasingly rely on the automator to perform workflow automations. In most of the cases our consultants develop and maintain automation packages. To constantly deliver high quality, all requirements get CATWOE checked before we start with the technical development. Of course the output gets checked against CATWOE too. During technical implementation consultants use 3 different environments – Development – Sandbox and Production.

In addition to that we implemented the possibility to save versions within each environment in order to encourage experimentation. Encouraging experimentation likely increases the quality and readability of the automation package further.

automator-versions

How does it work?

It is very simple:

  1. Create a new version
  2. Experiment
  3. Whenever you want switch to a previously saved version
  4. Happy!

man-in-a-party-dancing-with-people-3

k.konwalin@techwork.at

During the summer 2 – Automator audit report

Following the last blog post, the 2nd major development for the automator during the summer 2017 is the “Automator audit report”.

Purpose

The purpose is to get a document about automator packages describing the nature of your automations. It can be used for internal and external audits or to get a quick overview about what’s happening.

automator-audit-report.png

A side effect is that switching costs get lower again. That means the following: should you ever decide to switch from the automator environment to your own development- and operating- environment your Java Script developer gets a nice overview what needs to be configured. After that your JS developer simply uses the automator package code and develops missing components. Your risk to use the automator is basically zero.

automator-logo

k.konwalin@techwork.at

During the summer – physical button

We are going to develop 2 new automator capabilities in Summer 2017.

  • Physical button
  • Automator audit report (will be a another blog post)

Physical button

Everyone can push a button right? We are connecting the physical button to ITRP.

bttn.png

Well, but what could be a purposeful function?

An Example

One example is printer maintenance. Some companies outsource printer maintenance completely i.e. the vendor is changing, maintaining everything except adding paper. Right now, without the button a toner change request could work like that:

  • User goes to the printer
  • Printer is low on toner
  • User contacts the Service Desk
  • User uses another printer
  • Service Desk looks for the Printer Serial No.
  • Service Desk calls the printer company or writes an email

With the button it will work like that:

  • User goes to the printer
  • Printer is low on toner
  • User pushes the button
  • A Service Request in ITRP will be created automatically and an email including Serial No. etc. goes to the printer company, of course automatically

Result:

Time and nerves saved for Service Desk staff.

Other Examples

There are many other examples for using such a button. The spectrum goes from ordering Pizza, creating a request because the vending machine run out of coffee to automate orders of spare parts.

automator-logo

k.konwalin@techwork.at

 

 

 

Lift the CMDB to a completely new level

automator-logo

The CMDB (Configuration Management Data Base) in ITRP can not only be used for ITIL’s definition of a CMDB but also to provide configuration parameters for automator packages. That way you can specify the specifics of your automations in ITRP.

Business case

Especially service forms add major capabilities to ITRP’s Self Service. Recently I released the Service forms blog post. There the automator provides a simple wizard and saves the customer entries in the request module and provides a couple of other automations like adding the person if the person can not be found in the people module and so on.

service-forms-automate-io.png

Advantages of that approach

There are several advantages for ITRP administrators:

  • Configure the behaviour of Service forms within ITRP
  • No coding necessary
  • Maximize the business value with one automator package

Real world examples

  • Structured surveys
  • ITRP wizard – step by step easy to use Request Fulfilment front end for customers
  • CI based Self Service form

Conclusion

Automator service forms can be configured for different purposes by using the ITRP CMDB. That way business benefits can be maximized in an easy way.

k.konwalin@techwork.at