For Outsourcers, Service Item Portability is a Must Have—Part 3

By Brett Norgaard
(Part 3 of a 3 part series)

In Part 2, we argued that service item portability must also be configuration driven in a service provider environment since it is most likely changing and under increasing pressure to deliver self-service and co-created services… securely, of course. This entry will top line the business case for service providers adopting service item portability.

By employing reliable, tested and proven service items that can be offered in standard offers with additional optional service provides scale. Over time, service items from other clients can be incorporated swiftly, efficiently and effectively into the standard or optional offers. This also makes transitions swift and predictable.

Risk is lowered since portability means ease of bringing established service items into new environments. Service items based on configuration data also allow testing, piloting, and benchmarking with no additional programming with nothing to break.

Lower risk also contributes to saving time and money. One service provider cited a phenomenal gain in efficiency (16:1) when comparing business analysts configuring a service catalog vs. using developers to start from scratch.

Service item portability makes upgrades to the underlying service platform survivable. Service catalogs and service items can be pointed to the new version of the service platform and run immediately with no need for rework. This includes all branding and theming.

Time to market is shortened. One way that service providers innovate is by combining existing offers to make new offers that can be targeted at new markets. Having a low risk strategy and associated tactics enables a “sense and respond” style of innovation.

Service item portability yields a strong business case for service providers. The pieces, taken together, contribute to the ability to scale. In a world of increasing pressure on service margins and operating income, scalability is a welcome “ability.”

The Myth of the IT Service Management Upgrade

By Brian Shealey

In the IT Service Management space, it seems as though organizations are on a continual quest to upgrade to the latest and greatest version of their IT service management platform. And, like everything in life, newer is always “better,” right? Well… it depends!

An important question to this organizational pattern of perpetually upgrading that rarely gets answered is “Why are you upgrading?” What’s the purpose of upgrading today to version 7.x, when version 8, 9 or 10 will be released in the next six months? You know that the next version released will include even more feature functionality than is available today. So, if you are upgrading your ITSM platform to the “latest and greatest” version, you will not achieve a final state of “upgraded,” but instead you will be doing the next project in the life cycle of the system. There is no perfection in the world of IT service management tools. It is a myth!

Contradictions of Intent

If you actually pose the question “Why are you upgrading?” to an organization preparing for, or in the throes of an upgrade, the responses will vary. Many organizations will say, “We are adopting ITIL as a strategy and need an ITIL-aligned toolset.” Sometimes, you may hear, “We need to be more out-of-the-box because it is painful to move our customizations to the new versions when we have to upgrade.” And then, there’s my favorite: “Our vendor doesn’t support our version because it is too old.”

I know there are many other reasons, but the vast majority of reasons customers give for upgrading fall within those three categories. The real underlying question that is relevant to a successful upgrade is: “What is the business benefit of the upgrade?”

In other words, does this upgrade help us sell more widgets as a company, deliver our services better, or support our products better? In some cases it may, but I think to stop and ask this question along the way is done less often than you would think by IT organizations.

I admit—some upgrades do fix bugs and/or enhance functionality, making the organization more efficient through a better-performing toolset, alignment to a need, etc. From my experience, most organizations are continuing the path of upgrading with the hopes that the latest version/upgrade will fix all of the issues (perceived and otherwise) with their ITSM platform. Rarely do we see organizations stop and ask, “What is the business benefit of this upgrade?”.

Adopting ITIL Aligned Tool Set

ITIL is designed as a framework for aligning IT with the business. Therefore, an upgrade to “align with ITIL” doesn’t make sense. According to ITIL principles, the goal of an upgrade of any system should be to make the business more efficient. Upgrading for the sake of ITIL alignment is a contradiction in itself.

Need a More Out-Of-The-Box Solution

In the premise “We are too customized, and upgrades are painful,” there is also some inherent contradiction. If you are only upgrading to out-of-the-box ITSM because upgrades are perceived as painful. I would argue that the upgrade to ITSM definitely doesn’t solve this issue. ITSM tools are very complex. Upgrading from one version to the next, regardless of vendor, is often just as painful, if not more so, than upgrading a custom application that was aligned to the company’s needs from its inception. You not only have to deal with new tools, but also with major process changes from the way workflows were handled in the custom tool. With out-of-the-box ITSM apps, workflows are designed generically, with no thought of your company’s needs. Your processes must be changed to fit the vendor’s out–of-box ITSM platform workflows, or you are stuck customizing the new application, defeating the purpose of trying to be out-of-the-box. It’s a contradiction in intent.

The reality, in my humble opinion, is that this is actually driven by the ITSM vendor. With the right marketing and positioning of these out-of-the-box ITSM tools, they can appear to be a much better option to the company than the old, custom ITSM application.

Unsupported or Old Version Reason

This common reason for an upgrade has to do with supported versions of products. If a vendor discontinues support for specific versions of their software, and your organization sees the risk as too great to have an unsupported version of the ITSM tool, then you may be forced to upgrade. However, it’s important to really understand what you are getting.

For instance, if you upgrade the core component of your ITSM tool, and it creates more issues from a management, administration and cost standpoint than the unsupported old version, you may want to reconsider the upgrade. It is usually a smart decision to look around once in awhile to see what others are doing. Maybe look at alternatives to the upgrade, third-party support or another toolset altogether. It never hurts to take time and gain perspective prior to making decisions that are potentially very costly. In some cases, the cost of an upgrade may equal the cost of a complete replacement of the current tool set.

The Reality of the Upgrade…Happiness Is Not a Destination, and Perfection Does Not Exist

Here is the reality of an ITSM upgrade: An organization using an ITSM system is never going to be upgraded, or current, enough. Vendors will continue to put out new versions of their products to solve issues, fix problems, be more competitive, or just make their product “better.” However, is that version of better actually better for you? That is always an important question to ask.

Specifically, I believe that what’s best for Company A is: What is best for Company A.

Pardon the Yogi Berra-ism, but what I mean is this: Every organization has its own set of unique challenges. There are costs to those challenges, and problems to be solved specific to that organization. An upgrade is a concept that is driven into the mind of IT managers by their ITSM vendors—as a “must have” for whatever product they are using in pursuit of IT service management perfection.

There is no such thing as perfection in IT service management. Not in processes, not in technologies and certainly not in people. If you can invest in tools that allow you to continue improving your business and better deliver services both internally and externally, you are on the right track. A “good” upgrade is one that solves challenges in a cost-effective way and helps improve the business of the organization.

A friend of mine would always say, “Happiness is not a destination.” I think that certainly applies in the world of managing and maintaining ITSM platforms.

 

So…You’re New to Kinetic Request, Kinetic Survey and Kinetic Calendar!

By Derick Larson

We love new customers (no surprise there), because new customers always have the most questions. Here are some of our most common questions from new customers—generally about installs—and some answers.

Q. What version(s) of BMC Remedy do you work with?
A. Kinetic Request and Kinetic Survey are compatible with BMC Remedy ARS 6.3 through the current Remedy ARS release (Version 7.6.4 as I’m writing this). Kinetic Calendar is compatible back to Remedy ARS 6.0.

Q. What operating systems do you work with?
A. We will work with anything that BMC Remedy runs on, including Windows, Linux, and a variety of Unix platforms (like Solaris, AIX and HP-Unix).

Q. What web server applications do you work with?
A. The vast majority of our customers use Apache Tomcat. We also have customers using ServlerExec, and WebSphere. We have had customers using Web Logic, but they have moved to Apache Tomcat.

Q. Do you need special permissions (BMC Remedy or otherwise) to complete an install?
A. The person doing the Remedy install needs to have Remedy Administrator credentials to use during the install. The person doing the web server install should have all access permissions to the web server directories.

Q. How long does an install take?
A. It depends on which product. Kinetic Calendar typically takes less than a day. Kinetic Survey typically takes 1-2 days to get installed and hooked into your processes. Kinetic Request typically takes up to 5 days to install and get all the samples working properly. Once the products are installed—it is normal to then have some sort of project/consulting to make surveys that address your business goals or requests that solve your business problems/initiatives.

Some great ways to really mess up and delay an install include: 1) Don’t show up to meetings for the install—no really, happens more than you think. 2) Outsource the web server to company A, BMC Remedy to company B, management of IT to company C (hey if it hadn’t happened we wouldn’t put it on the list).
3) Don’t give permissions to the server/web server that the software is installed on.

Q. Can I get the installation guide so I can prepare for my install?
A. Absolutely! It is available on our web site at:
http://www.kineticdata.com/Products/KineticRequest/Documentation.html

Q. Besides the BMC Remedy version are there any other requirements to run your software?
A. The only other requirement we have is a minimum version of Java, specifically the 32-bit Java Development Kit (JDK) 1.5 or greater.

That covers most of the common questions we get in support from new customers. If you have any specific questions, please contact us directly at support@kineticdata.com.


Business Service Management—Your Business Your Way

A Vision from Down Under
By Michael Poole

I don’t admit it to many people as it dates me (in the way carbon dates dinosaur bones), but I have been in the IT industry since before it was called IT. It was called EDP (Electronic Data Processing) before IT. Yes, the pre-historic days of punch-tape and punch-cards, real TTYs and mainframes that would heat a good sized stadium in the middle of a Russian winter.

Coding sheets, print-outs on continuous paper stacks our interface to the computer, Assembler, FORTRAN and COBOL were language options—not a wireless connected MacBook and Eclipse.

In those days, we were restricted, not just by the hardware and languages, but by the limited vision of what we were allowed to do.

Through the years, I have seen EDP evolve into IT. We’ve moved from mainframe and dumb terminals through client-server, PCs, workstations, GUI, Various flavours of windowing systems—yes there were alternatives to Microsoft once including X-windows, GEM, NeXTSTEP, OS2, networked PCs, proprietary eMail systems and now the internet and Web.

In all this time, functionality and user experience have improved; applications have become more intuitive and the web browser has become the main interface between users and applications.

At the same time, users have both become more computer literate yet simultaneously less accepting of applications and environments restricting them and delivering limited Web functionality.

Web 2.0 is here, Web 3.0 is around the corner, and users now expect that every site will be as slick, functional and active as Facebook or Twitter.

In IT, we are still happy to have a character based terminal access to some applications and clunky GUI interfaces. Why? Because we are used to them, and they still get things done.

I think that this acceptance by IT is the reason some leading ITSM vendors are able to get away with providing a bare-bones Web portals and a complex and time-consuming processes to expose IT Services to users. Anything that is not their way of doing something is discouraged. To do anything with a sophisticated, active, user-friendly Web interface requires moving away from the OOTB and developing what some vendors call “Advanced” (read: “costly, time-consuming and still restricted by our environment”) forms. What used to be “Your business your way” has now become “Your business our way.”

But users no longer accept that and, increasingly, neither do those in IT. And those in IT who don’t like that approach do like working with Kinetic Request. We at Kinetic Data still believe in “Your business your way!”

Take a close look at Kinetic Request if your business needs:

  • Multiple service catalogues with individual styling, look and feel.
  • To incorporate a mash-up of another site in a service item or portal.
  • A unique approval process.
  • To implement a service catalogue without upgrading.
  • To provide unique service catalogues feeding into one ITSM system.
  • To integrate with this bespoke application.
  • To include multi-page request forms.
  • Multiple ways to display requests based on role, location, language, division, group or user.
  • To trigger tasks outside of the ITSM system without having to integrate through the ITSM system.
  • To cater for non-IT functions.
  • To define every request as an ITSM object—an incident, change, work-order, problem etc.
  • To enable rapid change.

Kinetic Request is designed to be flexible and powerful enough to let me say, “Yes, we will do your business your way” and it won’t cost you an arm and a leg.

So if you want a SRM environment that you are proud of and deliver value to your users, then open a window, lean out and shout, “We need to do our business our way!”—and give us a call—we can only say, “Yes—let’s do it your way”.

Please excuse the spelling of “catalogue” in this blog—here at the top of the world, we spell like the English. 🙂

 

For Outsourcers, Service Item Portability is a Must Have—Part 2

By Brett Norgaard
(Part 2 of a 3 part series)

In Part 1, we explored the dimensions of service item portability to get an idea of how vast the challenge is to run the same service item in different versions, instances, clients, and even with the same environment (test vs. production). Needless to say, trying to keep up with programming, coding, filtering, etc. no longer works. This is especially true for service provider’s stringent multi-tenant environments. With the expansion of service catalogs, more and more end users are starting to enjoy the benefits of self-service, co-created services and greater interactivity.

The customer-facing portion of the service platform (front end) needs to be truly web deliverable configurable in order to meet the demands of a service provider with multiple tenants. A reliable configuration-driven system removes the risk associated with programming or altering the source code of the underlying service platform. Even well written and documented code changes can wreak havoc at upgrade time when service catalogs (and service items) that used to work now do not. A configuration-driven strategy will also allow the service catalogs and the component service items to be uniquely branded and themed. In a world where clients expect things their way, doing so must not increase the associated cost, risk and time of personalizing the experience.

The ability to test, combine, and reconfigure service catalogs is also an important consideration for service providers. Configuration data does not change the underlying application code so testing and piloting can happen as often as needed. Innovation happens more easily when the risk of experimentation is removed.

Service providers can also build standardized sets of service items (in service catalogs) that can be deployed (configured, branded and themed) in a fraction of the time normally required. Optional service items can be configured as well for premium offers if the service provider wishes. Best practices or inventions from one client can be captured and re-deployed across some or all of the clients. Branch-based organizations can have processes built that call out needed materials and resources and replicate them to all locations swiftly and affordably. Every branch can be an experiment in creating best practices that can be replicated across all branches. And for service providers, this can extend to more than one customer for real scalability.

Configurability of service items in the service catalog in such a way that makes them reusable and portable afford the savvy service provider with a scalable competitive advantage. In the next part, we’ll examine the business benefits of service item portability more closely.

For Outsourcers, Service Item Portability is a Must Have

By Brett Norgaard
(Part 1 of a 3 part series)

Recently, we participated in and reviewed several deals involving help desk consolidations, platform migrations, system upgrades, and the transitioning of new clients onto the standard service delivery platform. The constant? Change. Movement. The challenge? Service items are tied to, trapped if you will, to the specific instances, version, client (in a multi-tenant environment) or role (development vs. production server) and do not migrate without extensive rework, manual intervention or a complete re-do.

Let’s examine these dimensions of service item portability a little closer. Many service providers have multiple instances of the same version of their service platform. There are many many reasons for this—consolidations of multiple providers, client requirements involving security/privacy/regulatory considerations. Several service providers have reported issues with the reality of moving service items between different instances of the same version of their service platform. Issues tend to arise when “best practice” service items are captured and uploaded to the new, but same version, service platform.

Due to some of the same reasons cited above, many service providers end up with many different versions of the same service platform. Problems start to appear in this case around the upgrade procedures. Many service providers have had to redo vast portions of the service items post upgrade.

Some service providers have intended to offer a standard set of services to a set of clients on a multi-tenant platform. Challenges arise as each client requires customizations including branding and theming.  In order to deliver on this promise, service providers have resorted to extensive filtering which adds complexity to the code which move often manifests during upgrades resulting in going back to the drawing board.

One service provider reported that service items created in the test environment were not able to run in the production environment without extensive manual rework.

Two fundamental issues are at work here and conspire against service providers and their service platforms. Multi-tenancy and Self-Service. The major service platforms have concentrated on and solved the back office issues surrounding incident, change, problem and asset management. Today, each client wants service their own way. This means that they demand a unique experience—incorporating self-service, co-creation of services, and a more engaging overall experience. This is a challenge of the front office, client-facing part of the application. The usual programming and customizations of the past era no longer solve but instead work against service item portability. In our next entry, we will explore how a secure, configuration driven strategy addresses the issues of multi-tenancy, self-service with a unique experience for all.

 

How Request Management Could Improve the Homeowners Insurance Claim Process

By Nancy Nafziger

Imagine coming home after a vacation and finding your house robbed of all your personal belongings. In the back of our minds we think, “It will never happen to me…” But, I’m here to tell you, it did happen to me! And to describe how insurance companies can vastly improve their homeowners’ claims process with a request management system.

What happens after you are robbed?

Once a police report is filed, you need to contact your insurance agent. The agent will file the claim and a claim representative will contact you. The claim representative will send you manual inventory forms and email you a link to download electronic inventory forms. On the inventory forms you will list your personal belongings that need to be replaced. The inventory list includes item number, item name, manufacturer, purchase location, replacement value and other miscellaneous information/documentation. You need to submit the forms via snail mail or scan the forms and email them back to the claim representative. That’s right—no online option!

What happens after you file a claim?

After the claim representative receives your inventory forms via mail or scanned images in email, claims are processed in the order in which they are received. The claim rep reviews the forms for approval. Then he or she delivers the forms to a data entry person who manually enters the inventory lists and delivers the inventory list back to the claims rep. The claim rep and or other staff member researches the recorded replacement values you listed for accuracy. This is a manual and time-consuming process. Since I market Kinetic Data’s products, I know there is a more efficient way to process claims.

How can insurance companies and their customers benefit from a request management system?

Insurance companies can dramatically improve operational efficiency (not to mention making the process simpler for their customers) by revamping processes and implementing a request management tool. The workflow automation provided by a request management tool will reduce costs by rapidly and efficiently increasing the speed of their claim process.

Imagine the cost savings on staff labor time if the electronic inventory forms were emailed (or information was entered directly online) and inventory data was retained so that the data entry person did not have to re-enter the inventory? And the reduction in data entry errors? And the time saved by using an automated workflow so that an insurance rep doesn’t have to manually obtain approvals?

Insurance companies have multiple requirements for their claim processes. Therefore, processes require flexibility. Within a request management tool like Kinetic Request, its workflow engine, Kinetic Task, provides the flexibility to deal with the multiple requirements needed by different claim processes. Companies can improve control and automate tasks and approvals with Kinetic Request.

With a request management tool, insurance companies will retain loyal customers. Request management tools offer self-service customer portals. Insurance agencies can configure the customer portal to enable claim status checks—24/7. If a customer is pleased with their claim fulfillment experience, and understands that the claim was processed in a rapid and efficient way, the customer will continue their homeowner’s policy with his or her insurance company and not search for a new one. The customer may even recommend the company to friends.

Home inventory list

One last thought since robbers don’t give you advance warning, I recommend protecting your property by producing a home inventory list. This takes time, but the frustrations it will save you later will more than make up for it!

 

When Is It Time to Upgrade?

By Derick Larson

Two weeks ago Kinetic Request and Kinetic Survey released its most recent patch (v5.02). The most common support question I recieve about upgrades includes, “Do I have to upgrade?”  Normally, the answer is, “No.”

I always hope that customers will keep up with the latest version of our applications, but it is not required. Please note, there are  no versions of our product(s) that are unsupported. Upgrading, especially major releases, can involve a considerable amount of time and effort in testing and verifying your functionality. The only reason I actively encourage customers to upgrade is to take advantage of a specific feature or bug fix that directly relates to their situation.

The benefits of upgrading depend on the specifics of the upgrade itself. Specifics are found in the release notes included in the upgrade package. The most current release notes also contain details for all past upgrades and releases.

Examples of features included in our latest release, Kinetic Request and Kinetic Survey (v5.02) include:

• Added ability for task trees to run for approval submissions
• Added a differences report when importing over already existing templates
• Updated pattern matching for Time/Date field
• Updated documentation to reference 32 bit requirements
• Better compatibility with mid-tier

Upgrades are broken down into two parts, Remedy workflow and form changes and web server changes. You will need to use the Remedy Admin Tool/Developer Studio and possibly the Import tool for any Remedy changes. For web server updates it is normally just a copy/paste over the current web application directory.

Have questions about your own upgrade process? Feel free to contact us.