Ivanti Australia HEAT Melbourne Sydney Adelaide Perth ANZ New Zealand APAC

Password Resets. Incident or Service Request?

Can Password Resets even be logged by a user? Of course!

  1. There are many passwords besides your Single Sign-On (SSO) password.
  2. Self Service can be configured to allow anonymous Incidents and Service Requests.
  3. You could always ask a colleague to log a ticket for you.
  4. You could just pick up the phone and use the Interactive Voice Response (IVR) System, Ivanti Voice to submit a password reset.
  5. You could just pick up the phone and call the Service Desk who then logs the Ticket.

Of course there are those famous hostage and drive-by situations (my favorite Source codes), but I won’t count those. And here you were about to laugh out loud proclaiming you can’t log a ticket without a password. Not mentioning any names. You know who you are. Shout out to my friend in Australia 😉

Now that we have that out of the way….

Incidents (Break/Fix) and Service Requests (New/Change to Service) are often long debated by companies new to ITSM (IT Service Management).Password Reset Requests do not make the differentiation any easier.  Are they a break/fix or service request?

The subject actually goes much deeper as Incidents are viewed negatively.  More incidents, more issues, higher IT instability.  While Service Requests are positively viewed as a demand for IT services.

Password Resets – Incident or Service Request? (Re-recorded Sep 24) Ivanti HEAT Neurons Podcast | Best Practices | Tips & Tricks | Latest Solutions

Incidents (Break/Fix) and Service Requests (New/Change to Service) are often long debated by companies new to ITSM (IT Service Management). Password Reset Requests do not make the differentiation any easier.  Are they a break/fix or service request?    Can Password Resets even be logged by a user?   Of course! There are many passwords besides your Single Sign-On (SSO) password. Self Service can be configured to allow anonymous Incidents and Service Requests. You could always ask a colleague to log a ticket for you. You could just pick up the phone and use the Interactive Response System (IVR), Ivanti Voice to submit a password reset. You could just pick up the phone and call the Service Desk who then logs the Ticket.   The subject actually goes much deeper as Incidents are viewed negatively.  More incidents, more issues, higher IT instability.  While Service Requests are positively viewed as a demand for IT services. Do you have an Ivanti Podcast Topic or Question?  Submit it at podcast.a19consulting.com

Service Request Parameters and Request Offering UNIQUE ID

Best Practice for designing Request Offerings is to always set a Unique ID for your Request Offering form controls.

Unique ID plays a critical Design & Architecture Role

Unique ID is the Parameter Name which in turn is used for searches, filters, and reporting for Service Requests.

Don’t Do This!

What if you don’t set unique id? You will be in a world of pain when you try to search, filter, or report on Service Request Parameters. In the example above you can see the unique id for the Approving Manager for example is combo_10. That’s not meaningful now is it.

You always want to set a your Unique ID to a meaningful name.

Do That!

But that’s not all… You have many request offerings which have many service request parameters. So you need to use consistent unique id’s across all your request offerings.

Use a Data Dictionary for your Service Request Parameters and use it whenever you’re defining Unique IDs to look up existing Unique IDs and to add new ones.

Data Dictionary

Contact me for a copy of my Data Dictionary!

Service Level Agreements SLA Holidays US Canada Australia UK Escalations Horus of Operation HOP Ivanti Business Hours

The SLA’s red headed step child

When it comes to Service Level Agreements (SLAs) there is one important configuration that’s overlooked or forgotten.

When it comes to Service Level Agreements (SLAs) there is one important configuration that's overlooked or forgotten. Holidays and Exceptions You've likely seen me post Holiday message on Instagram for the US, Canada, UK, Australia, Europe, Singapore, etc.  Make no mistake about it, Holidays are important.   Your SLA clock is likely ticking away when Incident, Service Request, and Task SLAs should be paused! It's somewhat of a straight forward process to configure SLA Holidays & Exceptions. There are two types of "Exception" configurations for your Hours of Operation (HOP) Calendar, aka Business Hours: Recurrent Manual Dates Continue reading at blog.a19consulting.com

Holidays and Exceptions

You’ve likely seen me post Holiday message on Instagram for the US, Canada, UK, Australia, Europe, Singapore, etc.. Make no mistake about it, Holidays are important. Your SLA clock is likely ticking away when Incident, Service Request, and Task SLAs should be paused!

It’s somewhat of a straight forward process to configure SLA Holidays & Exceptions.

There are two types of “Exception” configurations for your Hours of Operation (HOP) Calendar, aka Business Hours:

  • Recurrent
  • Manual Dates

Recurrent are pretty straight forward, for example every New Year’s Day, which is the 1st non-working day of January. That’s right, not the 1st of January, because that could fall on a weekend and then get pushed forward to Monday.

Manual Dates can be further grouped into two categories.

Recurrent Exceptions

For example, Fourth of July in America, Canada Day on July 1st, and all sorts of other country/state holidays have a set date that we can set up as recurring BUT there are exceptions for when these holidays either a) fall on a weekend or b) your company observes additional / substitute days.

Yearly Set Exceptions

Then there exceptions that occur yearly that do not have a set schedule or date. For example Easter Friday, Easter Monday, and in Australia the Queens Birthday is even observed in different months and days per region all together.

Manual Dates you will want to set for the next 5 or 10 years and then create a reminder or task to update these again!

Clear as mud right? Well wait, there is more. Some states/provinces/territories or even countries may observe holidays of their own. In which case you have to either come up with a “blended” calendar, use your company’s official HR calendar, or create custom hours of operation calendars for the states/provinces/territories or countries and use the customer’s location to drive the HOP used for SLAs. But that’s a topic for another day!

Be sure to catch my Ivanti HEAT ISM Podcast here https://open.spotify.com/show/2vuxE1mrud0as77HfS0YQD #Ivanti #HEAT #IvantiITSM #IvantiServiceManager #Podcast #IvantiAssetManager #Consultant #Developer #ProfessionalServices

Ivanti HEAT ISM Podcast

My podcasts cover popular Ivanti Service Manager (HEAT ISM), SDLC, ITSM, ITAM, and ESM Topics.

Why Podcasts? Sometimes podcasts are a great medium to share information. Podcasts are quick and easy to create, powerful, and also convenient to listen to on the morning commute, lunch break, or while travelling. Plus you can download Podcasts for offline listening.

Personally I like to download a few hours worth of Podcasts whenever I’m travelling or stuck somewhere and want a break from reading or watching videos.

You can find my Podcast on

Password Resets – Incident or Service Request? (Re-recorded Sep 24) Ivanti HEAT Neurons Podcast | Best Practices | Tips & Tricks | Latest Solutions

Incidents (Break/Fix) and Service Requests (New/Change to Service) are often long debated by companies new to ITSM (IT Service Management). Password Reset Requests do not make the differentiation any easier.  Are they a break/fix or service request?    Can Password Resets even be logged by a user?   Of course! There are many passwords besides your Single Sign-On (SSO) password. Self Service can be configured to allow anonymous Incidents and Service Requests. You could always ask a colleague to log a ticket for you. You could just pick up the phone and use the Interactive Response System (IVR), Ivanti Voice to submit a password reset. You could just pick up the phone and call the Service Desk who then logs the Ticket.   The subject actually goes much deeper as Incidents are viewed negatively.  More incidents, more issues, higher IT instability.  While Service Requests are positively viewed as a demand for IT services. Do you have an Ivanti Podcast Topic or Question?  Submit it at podcast.a19consulting.com
  1. Password Resets – Incident or Service Request? (Re-recorded Sep 24)
  2. Typical Ivanti Implementation Timeframe
  3. SLAs red headed step child
  4. Ivanti Cloud Status Updates & Maintenance Notifications
  5. What is the difference between an Incident, Problem, Service Request, and Change Requests?
email summaries notifications ivanti heat itsm ivanti service manager ivanti asset manager developer consultant

Email Summaries

It is no secret that I strongly believe Email is a productivity tool from the last century and recommend against enabling one-off email notifications unless absolutely necessary.

A much better way and extremely advanced configuration is to create email summaries.

Some popular examples of email summaries are:

  • Daily SLA (Escalation) Email Summaries (combined with a19 SLA Indicator)
  • Daily Assignment (Task) Email Summaries
  • Daily Incident Email Summaries
  • Weekly Change Request Email Summary
  • Software Asset Management – License Reconciliation and Audit Summaries
  • Procurement Purchase Order Summary
  • Hardware Asset Management and Inventory Bar Code Scanning Summaries
  • Service Request Schedule Summary
  • Knowledgebase Activity Summary
  • Project Status Updates

Why would you opt out of one-off emails and implement email summaries? Email notifications become counter productive when there is a flood of email notifications for just 1 incident, service request, or task. Back in the day (last century) when ticket volumes were much lower, email made sense. In today’s fast paced Service Desk world, ticket volumes have gone up and turnaround times have gone down, requiring targeted emails, just-in-time (JIT), meaningful, precise and concise emails.

What happens when HEAT ISM End Users get overwhelmed with emails?

  • Recipients interact with outdated information in emails
  • Recipients spend more time on emails than the actual resolution
  • Recipients create email filters and frankly set and forget or ignore one-off emails
  • Morale goes down and the Ivanti Implementation‘s emails are deemed a nuisance

How to solve the Ivanti service manager email notification dilemma?

Balance, just-in-time emails, with precise, concise information, and email summaries.

When should emails be one-off and when should emails be summarized?

One-off email candidates are any time-sensitive emails, typically high priority. P1 and P2 Incidents Updates, P1/2 Tasks Creations and Escalations, Urgent Service Request for example.

Email Summaries should be employed whenever to expect frequent email notifications on the same subject (think business object) throughout the day. For example summaries of new tasks assigned and outstanding, every morning, or daily incident SLA/Escalation breach warnings and breaches.

What information should be in the email? Email notifications should be precise and concise and contain minimal information, less is more for sure, especially for one-off emails as the information can change quickly. Symptoms for example may get updated and journal notes are added frequently for high priority incidents, so it’s best to redirect the user to a link to open the incident in the HEAT ISM Application.

Advanced Ivanti Service Manager Configuration

How do you implement email summaries? This is an extremely advanced configuration topic that requires scheduled workflows, saved searches, quick actions, and use of the ChildFold and ForEachChild functions to create a custom email summary business object that is used to trigger and manage HTML emails as well as provide the user with a link to the email summary within the HEAT ISM Application, and Email Summary Dashboard for a better overview for executives, managers, service desk analysts, and end users alike.

The simple answer is that if you are still unsure how to implement Ivanti Email Notification Summaries, then seek a seasoned Ivanti Consultant that can get it done.

The estimated effort for a simple email summary is anywhere from 5 to 10 days depending on criteria. Please be sure to contact me or set up a discovery session to take your Ivanti implementation to the next level!

book discovery session with ivanti heat itsm ivanti service manager ivanti asset manager developer consultant
QR Code to Book Ivanti Service/Asset Manager (HEAT) Discovery Session
It is no secret that I strongly believe Email is a productivity tool from the last century and recommend against enabling one-off email notifications unless absolutely necessary.  A much better way and extremely advanced configuration is to create email summaries.  Do you have an Ivanti Podcast Topic or Question?  Submit it at podcast.a19consulting.com

PS: If you’re still reading this, here is another tip: Consider Targeted Mobile App Notifications and SMS Notifications as well!

PPS: Ask a19 Consulting about their a19 Email Summary Module for Ivanti Service Manager! The first 3 customers that mention my blog, get a special bonus.

Ivanti HEAT ISM UAT UserAcceptanceTesting Sample Test Data - Kifinti Solutions Consultant a19 Consulting

What Input Data is best for UAT?

While obvious to the most seasoned Quality Assurance Analysts and HEAT ISM Consultants, the gathering of UAT Sample Data can be confusing to some and is often poorly documented and executed.

Having the right sample data is key to successful User Acceptance Testing (UAT).

The worst thing you can do is test milli-vanilli and only make up input data without using real data. Using made-up sample data can be confusing to UAT Testers, difficult to follow, and lead to false test results.

UAT is all about validating business requirements and confirming that you can perform your day to day job functions. So why would you want to use some made up data? You don’t. You want to use real live actual data to verify that the new system or feature behaves exactly like your old system, whether HEAT Classic, another software system, Excel, manual forms, legacy application, and so on. In my 25+ years of Ivanti HEAT ISM Implementations I have not come across an implementation that didn’t have some sort of tracking tool or method, spreadsheet, or other artifact that can be used as sample data. Even handwritten logs could make up sample data, and I don’t remember the last time I have seen one of those.

Sample input data should be real data, from your existing system, whether it’s a database, excel sheet, paper forms, or another system or artifact. For example tickets from your old HEAT Classic system, Paper Forms from a manual system (Invoices, Logs, etc), if you’re going digital, or sample rows from an Excel sheet if that’s what you’re replacing. These are just some examples.

Tip: Create a “complete workflow” artifacts of examples from start to finish in the process. One of my clients recently added procurement workflows to the Ivanti HEAT System and created a PDF of sample data for the relevant process, from inception of the procurement request, approval, quote, shipment, receipt, asset tagging, stock administration, invoice, and payment. The artifact was through and included sample data from every step. Some digital, others print outs, and even handwritten notes on the invoices. All of which were important sample data for User Acceptance Testing. It was a one time effort by the Subject Matter Expert (SME) and was invaluable throughout UAT, Training, and overall for discussion purposes. Intangibles were positive user morale, adoption, and a clear understanding of UAT Testers as to what data to use and how the new system would benefit them relating back to how they were doing things before and how that was going to change in the new way of doing things. In other words, the sample data artifacts were valuable Training Knowledge and used for review and discussion purposes, and during ongoing UAT Status Calls and meetings.

Bottom line, use real data that represents the typical type of data to expect and the UAT Team members can relate to. Tip: Ask yourself if the data could be used for training purposes. If it can, then include it as an artifact for training documentation. If it can’t, then ask yourself if the sample data is a good representation of a typical day in the life of the end user.

Furthermore, keep in mind that when there are changes, upgrades, or issues, you will want to have sample UAT Test Data to fall back to.

Is 2 tests per UAT script enough?

Recently a customer asked me if 2 tests per User Acceptance Test (UAT) Script are enough.

This is a good question, UAT testing is key to successful Ivanti HEAT implementations and rollouts of major features/functionality.

How many UAT Tests should be performed per Test Case?

As many as it takes for you and your team to feel comfortable that you can perform your day-to-day job function.

Recommendation and Best Practice is a minimum of 5 tests per UAT Test Script.  Anything less is a risk that the client need to evaluate. Some detailed, complex, and high impact UAT Test Scripts may require at least a dozen of tests for the various scenarios that you have identified. It is better to test more than less, that’s for sure. Perform as many tests as it takes for you and your team to feel comfortable that you can perform your day-to-day job function.

Experience dictates that if UAT (validation of business requirements) isn’t thorough then the likelihood of post-implementation issues, gaps, and problems is much much higher, and can take more time and effort to address than during UAT.   

Intangibles like morale and perception of the new Ivanti HEAT Service Manager system/features can also be negatively impacted.

Also note that you are not bug hunting, so you don’t need to test every single feature and menu item, however you are testing that you can perform your daily job function, so test all the features related to the use case (business process) that apply.

It’s not unlike ordering a fleet of vehicles simply by kicking tires and doing a lap around the parking lot versus more extensive test-drives tailored to the company wide business needs. Sure, everything “might” appear fine, and “might” go fine upon delivery. But those are huge risks to take for a high dollar, high impact, high exposure item that ultimately could lead to work slow down or stoppage.

No matter how detailed your UAT Test Scripts, you need to have a good range of test case scenarios (sample input data) for every test script. Sample input data should be real data, from your existing system, whether it’s a database, excel sheet, or paper forms. For example tickets from your old HEAT Classic system, Paper Forms from a manual system, if you’re going digital, sample rows from an Excel sheet if that’s what you’re replacing. Bottom line, use real data that represents the typical type of data to expect and the UAT Team members can relate to. Tip: Ask yourself if the data could be used for training purposes. If it can, then include it as an artifact for training documentation. If it can’t, then ask yourself if the sample data is a good representation of a typical day in the life of the end user.

The time and effort required is usually negligible. Minutes per test.

A great amount of time and effort has gone into the Ivanti HEAT project, and UAT is a critical milestone in the Software Development Life Cycle (SDLC). So make it count and be thorough on your validation of business requirements, UAT that is.

UAT Test Scripts - User Acceptance Testing - HEAT Ivanti ITSM Service Manager ITAM Asset Manager Best Practices Trust the Process

Trust the Process

As you may have noticed, the last few Ivanti HEAT ITSM Blog posts had a common theme. UAT, Test Scripts, Pitfalls of UAT.

User Acceptance Testing (UAT) is without a doubt the most critical stage of the SDLC. This is where “the rubber hits the road”, and the customer and subject matter experts (SMEs) validate the business requirements.

This is also where typically some customers and SMEs tend to panic, get confused, worry, or simply get overwhelmed by the project at hand. Rightfully so, there is usually a lot at stake and the customer wants to make sure their business requirements are met, as does the consultant.

On one side, the customer and SMEs look up to the consultant for guidance drawn from years of experience, on the other hand, customers and SMEs also tend to think they know better.

So who is right?

Over 2 decades with HEAT Consulting, Business Analysis, and Project Management have taught me and reinforced, is that the customer isn’t always right and neither is the consultant. Looking at who is right is wrong! Instead of building a law case and looking to disprove one another, everyone needs to TRUST THE PROCESS.

If you have made it to UAT so far. Best Practice is to always review the steps taken (process) to-date.

  • Scope of Work was Signed Off by Customer
  • Business Requirements Elicited & Reviewed by Customer and Ivanti HEAT Consultant
  • Prototype Reviewed & Signed Off by Customer
  • System Testing performed by Ivanti HEAT Consultant
  • UAT Test Script Module implemented by Ivanti HEAT Consultant
  • UAT Test Script Examples provided by Ivanti HEAT Consultant
  • UAT Test Scripts created by Customer and SMEs
  • UAT Test Scripts imported into UAT Module by Ivanti HEAT Consultant
  • UAT Kicked Off
  • UAT Training Provided by Ivanti HEAT Consultant

…and the steps (milestones) ahead:

  • UAT Testing by Customer
  • UAT Test Scripts review by Ivanti HEAT Consultant
  • UAT Remediation (to address failed tests and gaps) by Ivanti HEAT Consultant
  • UAT Sign-Off
  • Go-Live (Rollout) Prep by Customer/SMEs, and Ivanti HEAT Consultant
  • Go-Live (Rollout) by Customer/SMEs, and lead by Ivanti HEAT Consultant
  • Go-Live (Rollout) Support by Ivanti HEAT Consultant
  • Post Go-Live (Rollout) Remediation by Ivanti HEAT Consultant
  • Minor Enhancements (if needed and within scope)
  • Major Enhancements (if needed and within scope)

In Summary, using the analogy of purchasing a car, the buyer (customer) has done their research and made a list of must-haves, and nice-to-haves (business requirements), identified the car type, model, and budget (scope) with the help of the dealership (Ivanti HEAT Consultant), and now it’s time to take the car (system) for a road test (UAT). This is where “rubber hits the pavement”.

UAT. This is where some customers tend to experience a little anxiety and suddenly question their very own requirements and the very system they helped build, see Common UAT Pitfalls for more details, while other customers shine and jump into the drivers seat and master the road test (UAT).

Acquiring a new car (System/Major Functionality Changes/Upgrades) can be overwhelming for many reasons, covered in the Common UAT Pitfalls Ivanti HEAT ITSM Blog Post. But like anything else in life, you need to do a self check and trust the process.

You’ve made it this far, sure the new car can be overwhelming, but once you hop into the driver seat (take responsibility) and go on that road-test (UAT), familiarize yourself with the new vehicle, adjust the mirrors, seat, study the controls (learning curve) and see how the vehicle handles (learning curve), you soon start parallel parking, emergency breaking tests, city driving, highway driving, and so on.

The road-test (UAT) is the time to stop kicking tires and take action. Trust the process and go for that test-drive. The goal is to report back any issues (UAT Test Scripts), collaborate with the family, (UAT Meetings with UAT Lead to review UAT Test Script Results), and ask questions (UAT Test Script Module has comments for the consultant), and not only CONTINUE with the road test (UAT Test Scripts), but go on several road tests (many tests per UAT Test Script), and before you know it, you master the new car (system).

The last thing you want to do is stop the road-test every time you are unsure (learning curve), have a question (Learning Curve / UAT Meeting), or feel something is not right (UAT Test Script Result). You keep driving and report back your findings (UAT Test Script results) and collaborate with the family (UAT Team) to see if your findings are issues or just a learning curve (new controls, new way of doing things), or terminology (gas tank versus fuel tank), or it’s a major change, like driving on the right side of the road to the left side (major system upgrade), which requires more test drives. Or maybe you’ve never driven a car before and you are upgrading from a motorbike, bicycle, or walking on foot (legacy systems, Excel, Word, handwritten notes). Assumption is that you’ve taken your driving test and have a valid license of course (experience in the business, and have used Windows and web-apps before). Nowadays web applications are intuitive, as is learning to drive a different type of car (sports car, SUV, mini-van, luxury car). The days of long thick training manuals and days of classroom training are in the past although training videos can be provided as needed to fill any major training gaps. In other words, a learner’s license and some time with an experienced driver are just as efficient as a 2 week intensive course. At this stage of the implementation all SMEs are typically well versed with handling a car (Windows, Web Applications).

The learning curve will vary and you must TRUST THE PROCESS. You’ve made it this far, and should feel confident you have the support of the internal teams and external Ivanti HEAT Consultant, however ultimately you need to do the test-drive. The Ivanti HEAT Consultant has already done his. Now is the time to roll-up-your-sleeves-get-to-work-test-test-test with the goal of testing and providing concise precise results back to identify any gaps and more importantly, CELEBRATE THE WINS, mark test results as passed. So focus on the EASY TESTS FIRST, you know the parallel parking, driving in the parking lot, city driving on a slow day, before you go on a multi-lane highway or off-road in the Rocky Mountains on one of the toughest terrains.

You will get there, just keep testing, and know that the combination of your planning of must-haves (business requirements), intimate knowledge of your business processes, and the extensive experience and guidance by the Ivanti HEAT Consultant will get you there!

ivanti-best-practices-by-a19-consulting-ivanti-professional-services http://ivanti.bestpractice.systems

What is the difference between an Incident, Problem, and Service Request?

Incidents are Break/Fixes for issues where something was working but stopped working, a single unplanned event that causes a service disruption.

Service Requests are for requesting new Services or changes to existing Services, for example for new access requests, change of access requests, New Hardware Requests, Repair Requests.

Note that many Service Desks are transitioning to this ITIL and Industry Best Practice, which can take time, hence there may be some “Service Request” and “Problem” tickets that are presently logged as Incidents.

Problem Records are used when a cause or potential cause of one or more incidents are identified whereas an incident is a single unplanned event that causes a service disruption. A problem can cause a single incident, or it can cause multiple incidents. And an incident may be traced back to a single problem or—sometimes—multiple problems. 
 
For example, if Wifi goes down in the board room once, that is an Incident. If we need to install Wifi or make changes to the Wifi configuration, that is a Service Request.  If Wifi in the boardroom goes down every Friday at lunch time, that is a Problem Record.  Problems can also be “potential causes”, in other words “preventative”, where you spot an issue, for example you notice that staff unplug the router when they need an extra power outlet.

It’s all the same isn’t it? No. Reporting and Metrics are perceived and interpreted by Senior Management and Executives that weigh Incidents negatively as Incidents are typically viewed as problems that negatively impact IT (IT screwed up) whereas Service Requests are perceived as adding-value (all hail IT).

Tip: Incident Cause Codes are also imperative for management and executive metrics and reports to identify the root cause of negatively viewed break/fixes. Some great examples of cause codes are “User Error”, “Knowledge/Training”, “Hardware”, “Software”, “Configuration”, “Vendor Configuration”, “Business Process”.

For example:

  • if the email service goes down frequently, is the cause a “Configuration”, “Hardware”, “Software”, or “Vendor Configuration” issue
  • if newly acquired laptops of a particular brand or model keeps crashing, is the cause a “Configuration” issue, “Hardware” malfunction, “Software” issue, or “Vendor Configuration”
  • if many incidents are logged for the newly implemented HR system, is it a “Configuration” issue, “Vendor Configuration”, “Knowledge/Training”, or “Business Process” issue

Incident Cause Codes and other additional metrics are vital to measure KPIs, root-cause analysis, management and executive reporting.