Ivanti HEAT ITSM ITAM Service Manager Asset Manager Kifinti Solutions a19 Consulting Australia UK Europe US Canada Toronto London Sydney Melbourne

What are the new Ivanti Cloud Data Centers?

In early 2021 Ivanti started moving their Ivanti Cloud Customers for Ivanti Service & Asset Manager to Azure Data Centers. The new data centers are below:

Europe

FFZ Frankfurt, Germany (Europe East)

IRZ Ireland (Europe West)

United Kingdom

LDZ London

APAC

NSZ New South Wales, Australia

Canada

TTZ Toronto (Canada)

Americas

NVZ North Virginia (Americas East)

WAZ Washington (Americas West)

PS: Click your data centre to see Ivanti Maintenance Notifications!

Ivanti Cloud Status Page FFZ Franfurt - Neurons - Service Manager - Asset Manager - HEAT Kifinti Solutions Latest Solutions a19 Consulting

Ivanti Maintenance Notifications by Landscape

The Ivanti Status Cloud Page is a great way of staying on top of notifications. Only snag is that there isn’t an easy way to see landscape specific updates for your Data Centre.

For example if your Ivanti Cloud tenant is in Frankfurt Landscape (FFZ), you still see all Landscape on the status page. Sure you could subscribe to email alerts for your landscape only, but lets face it, email isn’t a productivity tool, so I’ve gone ahead and created status pages that filter the rss feed, for example for Frankfurt FFZ, Australia NSZ, London UK, and Ireland:

Ivanti Cloud Status Page for Europe East | Frankfurt | FFZ

Ivanti Cloud Status Page for APAC | AUSTRALIA | NSZ

Ivanti Cloud Status Page for UK | LDZ

Ivanti Cloud Status Page for Ireland | IRL

Be sure to contact me or leave a comment for a link to your Data Center!

ivanti heat neurons - holy trinity - stg uat production tenants - ivanti service manager ITSM - Ivanti Asset Manager ITAM

Tenant Review – Holy Trinity

On-Premise (Self hosted) and Cloud Ivanti Neurons, Ivanti Service Manager (ITSM), and Ivanti Asset Manager (ITAM) customers have 3 tenants (environments) that I like to call the “Holy Trinity”.

STG – Stage Environment for Development and System Testing by the Ivanti Consultant / Administrator only

UAT User Acceptance Testing Environment for End User validation of business requirements by the UAT Test Team

PROD – Production Environment

Any configuration changes to Ivanti Neurons ITSM/ITAM should always follow the SDLC (System Development Life Cycle), that is development & system testing in Stage, then push to UAT for End User Acceptance Testing, and finally upon UAT Sign-Off push the changes to PRODUCTION.

ivanti podcast - heat ism - ivanti service manager - former Kifinti Solutions Consultant - SDLC - ESM - UAT

Former Kifinti Solutions Consultant launches Ivanti HEAT ISM Podcast

Ivanti HEAT ISM Podcast covers popular Ivanti Service Manager (HEAT ISM), SDLC, ITSM, ITAM, and ESM Topics and is available on Anchor, Spotify, Google Podcasts, Apple iTunes, Breaker Audio, Castbox, Pocket Casts, Radio Public, Listen Notes, and of course via RSS Feed

your Ivanti Podcast Host

LONDON – April 27, 2021 – PRLog — “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.

I decided to create the Ivanti HEAT ISM Podcast as an extension to my Ivanti HEAT ITSM Blog as podcasts are more powerful than a blog entry and allow me to quickly share relevant Ivanti HEAT ISM Information,” says Gregor Anton, a former Kifinti Solutions Consultant.

Gregor
 is a unique and distinctive authority in the Enterprise Service Management space with his consulting and development experience and extensive insight to best practices going back to 1996 with the HEAT and now Ivanti Service Manager (ISM) and Ivanti Asset Manager (IAM) products.

Providing HEAT ITSM Best Practices and now Ivanti Best Practices, with his tried, tested, and true implementations, and upgrades, Gregor now focuses on his company, a19 Consulting, his a19 Ivanti Best Practices System, a19 Ivanti Mobile Applications (Android, iOS)Ivanti ITSM Blog, and now Ivanti HEAT ISM Podcast.

Gregor has been developing, streamlining, and implementing best practices and latest solutions for fortune 500 companies and Frontrange Business Partners (Change Control, Avante Solutions, Kifinti Solutions) and Ivanti Business Partners (Kifinti Solutions, DDS IT), worldwide.  The testimonials speak for themselves.

The ITxM Space (ITSM, IT Service Management, ITAM, IT Asset Management) has never been more exciting, as is the transformation to ESM (Enterprise Service Management).

Are you getting the most out of your Ivanti Implementation?
You are NOT.  GUARANTEED.
Not until you contact a19 Consulting to take your Ivanti Implementation to the next level!

PS:  Have an Ivanti Topic or Question you’d like us to cover?  Submit at http://podcast.a19consulting.com/

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.