A Vision From Down Under
By Michael Poole

Last week I was a part of the Service Management Forum (SMF) that one of our larger clients in Australia has formed to bring all stakeholders in the IT area together to plan and implement the future of IT support and service delivery.

With a base of over 70,000 users geographically spread over an area of 809,444 km² (312,528 sq mi—nearly 3 times the size of Nevada) it is a vital matter .

With a new leadership, they are now wanting to embracing ‘Shift to the Left’ or ‘Level 0.’

What is ‘Shift to the Left’? What is ‘Level 0′?

Let us look at the standard support model we all know and, perhaps, love.

It starts at Level 1 with the Help or Service Desk operator logging and hopefully resolving incidents or requests. If this is not possible, we move through Levels 2 and 3 etc. of the support and service layers. In this model, the user who contacts the Help Desk takes no active part in the correct resolution or fulfillment process. The support and service team use various tools to get to a resolution. These may include: Call Scripts, Knowledge Bases both formal and informal, automated fulfillment services/applications, interaction with other team members etc.

If we look at the support levels as a series running from left to right with the lowest—Level 1—on the left and then add Level 0 (the user) to the left of Level 1, then we have a ‘shift to the left’ with ‘Level 0′ as the first level of support.

Level 0 is all about creating an environment where the user can commence and, with the right tools, resolve an incident or fulfill a request WITHOUT having to involve the conventional support and fulfillment teams.

Let’s admit it, ‘Level 0′ can be a challenge to conventional support and fulfillment structures. The Help Desk is a well established and understood method of providing support to users. Users and support teams both can feel  uncomfortable with this model.

Done badly, it can result in frustration for the users, who feel that they are being abandoned and the support team feeling that they are being ‘put out of a job.’

Done well, the users will get a resolution faster and the support team—at all levels—will be engaged in the more challenging issues while not being overwhelmed by trivial issues that can be resolved easily.

In my next blog on this topic, we will look at the tools which enable Level 0 and, of course, how the Kinetic Suite of applications can be an integral part of addressing the challenges.

By Brett Norgaard

Sound journalism addresses a fundamental set of questions—who, what, where, when, how, and why—in the makeup of a good story. The reader learns facts and gains knowledge from reading a well constructed piece. Similarly, a well constructed service will engage the user and provide a memorable experience. Service Blueprinting is a technique that maps out the service interaction from the perspective of what the user sees as well as how they interact with the “onstage” visible and “backstage” invisible service delivery elements. There is also a visualization of the underlying support infrastructure that the service provider uses in the delivery of the service.

With the advent of online shopping, social media and the proliferation of mobile devices, today’s demanding users expect the same kind of experience, always on connectivity, interactivity, self-service that they receive from Amazon, FaceBook, and on their iPhone. Yet, service providers face an even higher bar, for they have to not only address the aforementioned characteristics, but they also have to handle high organizational levels of security, compliance, privacy, multiple levels of approvals, and more complex service requests than typical consumer interactions. Examples of these more complex processes include employee on-boarding, transitioning a new client onto the service platform, or doing both simultaneously while integrating with enterprise applications. Yet, service providers have to do this for multiple clients who may in turn have multiple divisions, departments, or offices.

And, a service provider always pits its current service against the “claims of better service” by rivals waiting in the wings. So, savvy service providers are adding interactive feedback into the service flow so that instead of waiting for the service to conclude before gathering feedback, are actually capturing valuable, relevant feedback that can be acted upon if triggers indicate a breach.

Good service for one client may not be good for another. It depends on what the service goals are for each client. Consider the case of a Health Care IT Service Provider that we work with—one hospital client sought to optimize around their doctors while another wanted to optimize around their patients.

As you can see, the demands on a service provider to deliver a well constructed, engaging, interactive, secure, compliant, and unique service for each client is no small order. The people, processes, and technology need to support all aspects of the service.

Starting with the technology, a platform that is configuration-based, secure, scalable, and operates in either a dedicated or multi-tenant mode is the first step. Next, and utilizing the aforementioned, the service provider should have several “experience shaping” levers at its disposal for its people to pull. The ability to request services and/or products bundled, unique approvals, and fulfillment is key. The ability to view times, dates, resources, and obtain status is also important. And, it is also vital to be able to gather real-time feedback so the service can be delivered or rectified if off track. Taken together, these service levers can shape the flow of service to the unique needs of their clients, truly addressing their business requirements and their processes.

Now there’s a story that you can write where you shape the who, what, where, when, how and why of great service.

翻訳で失われた

pierde en la traducción

потерял в переводе

No matter which way you say it, being lost in translation is not just the name of a Hollywood Romi-Com—it can be a nightmare for companies that need to support users in multiple languages.

Handling multiple languages is becoming a requirement for most companies. Globalization is one driver, but more and more, with a growth in the diversity of community languages within most countries, to provide the best and most cost-effective request management to our users, being able to present a user interface in a community language is becoming a necessity.

In Australia—one of the most diverse multi-cultural countries after the United States, most government departments and major corporations provide web-pages and pamphlets in a variety of community languages.

In Europe, while the EU has one currency, it most certainly does not have one language. Multilingual is an essential for business.

So how can make sure that we make sure that our users and business is not ‘Lost in Translation?’

Let’s first look at a what we are really talking about.

Internationalization, multilingualization and localization—Not the same thing!

Wikipedia has this to say about the topic:

The support of multiple languages by computer systems can be considered a continuum between localization (“L10n”), through multilingualization (or “m17n”), to internationalization (“i18n”).

• A localized system has been adapted or converted for use in a particular locale (other than the one it was originally developed for), including the language of the user interface (UI), input, display, and features such as time/date display and currency. Each instance of the system only supports a single locale and there is no explicit support for languages that are not part of that locale (although the character set may coincidentally be usable for other languages).
• Multilingualized software supports multiple languages for display and input, but has a single UI language which cannot be changed after installation of the software. Multi-locale support for other features like date, time, number, and currency formats varies as the system tends towards full internationalization. … In general, a multilingualized system is intended for use in one specific locale, but is capable of handling multilingual content as data.
• An internationalized system is equipped for use in a range of “locales” (or by users of multiple languages), by allowing the co-existence of several languages and character sets for input, display, and UI. In particular, a system may not be considered internationalized in the fullest sense unless the UI language is selectable by the user at runtime. Full internationalization may extend beyond support for multiple languages and orthography to compliance with jurisdiction-specific legislation (in respect of copyright, for instance) and other non-linguistic conventions.

While internationalization is the strategy that ensures that both local, legislative and language requirements are met for all possible environments and users, it is also the most complex and demanding and may not be the correct strategy—in fact it may be excessive in many circumstances.

So how can we decide whether we localize, multi-lingualize or internationalize?

As we deal extensively with user request forms and processes in our practice at Kinetic Data, here is a check-list—not comprehensive, but is a good starting point—for determining what approach we should take expressed with Service Requests in mind.

Localize

• The request form will only be accessed and fulfilled by users in locations that share the same language, information formats, and process requirements
• There are very few—less than 2 or 3—localized versions of a similar request type. More than that will make maintenance of multiple forms a time consuming process
• The process is unique for that location and cannot be adapted for other locations or languages etc.

Multi-lingualize

• The only difference is the display language
• Date/Time, currency etc formats are handled by the application environment
• It is possible to determine or have the user select the language
• The same form and process is to be used by all users in the all locales and languages
• Users need to be able to see the same form displayed in a choice of languages not dependent on locale

Internationalize

• There are differences in the form and processes requirements that are locale dependent
• The maintenance of one set of forms and processes is preferable to the maintenance of multiple forms and processes to cater for locale and language variations
• It is possible to determine or have the user select the locale and language
• The same form and process needs to be used by all users in all locales and languages
• The user may want to select a particular locale and language combination e.g. a user may be in Australia but want to view the request form in Vietnamese for a service that will be delivered in the United States and comply with that locale’s requirements

Kinetic Request has a number of features that make any of the strategies easier to implement.

As well, we have now developed a functionality in Kinetic Request that uses an industry standard Java language translation library to enable one Request Form to be displayed in multiple languages—including non-Roman script languages such as Japanese, Chinese, Arabic, and Hebrew. This functionality goes down to the level of selection field, menu labels and pop-up messages that may be in a Request Form or Catalog Portal.

Kinetic Strategies

Localizing

• Create forms and process for a base locale
• Either use those forms and processes as templates for new forms and processes or use Kurl  to create new forms and processes which have been modified for the next locale. NOTE: localization may not involve a change in the language of the form—for instance a form used in the US  can be deployed in Australia using the same language (ignoring the slight differences in spelling of some words), but the process requirements and field checking will be different for some fields e.g. State is common to both locales but have different different formats.
• Make the localised forms and processes available to each locale through a localized catalog or a specific URLs

           Advantages

• Caters for large differences in form and processes requirements with a reduced effort in creating locale aware forms and processes

Dissadvantages

• Large number locales and languages and processes changes can develop into  maintenance black-hole
• Introducing new locales and languages requires creation and modification of new forms and processes
• Reporting and auditing only on multiple forms and processes
• Lacks flexibility for multiple languages in one locale and visa versa

Multi-lingualization

• Leverage the ability of Kinetic Request to use the industry standard Java translation libraries to translate forms to the required language
• Create the forms and processes in a base language
• Populate the translation tables with the equivalent labels, display values and text strings in each target language
• Either scrape for or let the user select the language

Advantages

• Adding support for new language does not affect the form
• New language requires only editing of the translation table
• Changes in requirements only need to be applied to one form, process and translation table
• Changes or corrections  in translation applied through translation table not the form
• Reporting and auditing only on one form and process

Disadvantages

• Form or translation needs to cater for translation layout differences – size of resulting text or direction (e.g. Right To Left)

Internationalization

• Create forms in a base language
• Leverage Kinetic Request functionality to control fields and display layout – either at the server or client level – to cater for locale difference or requirements
• Leverage the ability of Kinetic Request to use the industry standard Java translation libraries to translate forms to the required language
• Create processes (e.g Kinetic Task trees) that are aware of locale requirements and differences
• Populate the translation table with the equivalent labels, display values and text strings in each target language
• Either scrape for or let the user select the locale and language

Advantages

• Adding support for new language does not affect the form
• New language requires only editing of the translation table
• Changes in requirements only need to be applied to one form, process and translation table
• Changes or corrections  in translation applied through translation table not the form
• Reporting and auditing only on one form and process

Disadvantages

• Form or translation needs to cater for translation layout differences—size of resulting text or direction (e.g. Right To Left)
• More complex initial form and process development

As you can see, Kinetic Request and Kinetic Task give you the ability to deliver the correct solution to your users so they are not ‘Lost in Translation!’

By Nancy Nafziger

In today’s competitive market, organizations are under pressure to provide visibility to the costs and benefits of existing and planned technology expenditures.

When considering technology, it is imperative for organizations to migrate to solutions that reduce the overall Total Cost of Ownership, (TCO). So what is essential for reducing TCO? Technologies that save time, reduce costs, reduce errors, and improve user satisfaction.

With that said, it is advantageous to consider technologies with self-provisioning features. Self-provisioning features have the power to reduce TCO. Let’s take a look at one technology that has made significant advances in self-provisioning—Service Request Management.

Leading Service Request Management solutions are automated and empower authorized users to self-provision their Requests. So how does this provide value? Self-provisioned Requests trigger a variety of automated processes that reduces time and eliminates errors. The lack of automation loads organizations with increased costs, security issues, and provisioning errors. Automating request fulfillment eliminates hours of staff time that was previously spent manually responding to requests.

In addition to reducing TCO, other self-provisioning benefits in Request Management include:

• Enables process owners to have full control of managing their processes
• Reduces support costs
• Enables compliance with governance audit and reporting requirements
• Empowers users with fast-response access to critical business services
• Improves user satisfaction through greater transparency and better management 

In summary, self-provisioning features in Service Request Management Solutions requests enable requests to be fulfilled more efficiently, faster, and at a lower cost.

By Nancy Nafziger

So what exactly is Service Request Management? According to Wikipedia, service request management, a key component of an actionable service catalog is the underlying workflow and processes that enable an IT procurement or service request to be reliably submitted, routed, approved, monitored, and delivered. Service Request Management is the process of managing a service request through its lifecycle from submission through delivery and follow up.

What’s the core reason for Request Management? In a nutshell, Request Management empowers organizations to standardize and automate service delivery management processes in order to increase productivity, improve response time, cut costs, and deliver superior business performance.

What does a Request Management solution actually do? It automates the processing and approval tasks for business service provisioning. Often, organizations associate Request Management with IT departments only. However, this is not the case—it can be used beyond IT. It is an enterprise-wide solution. Multiple departments have Request Management needs.

For example, what large organization doesn’t have HR onboarding process needs? Request Management enables HR departments to control request approvals and implement workflows that automatically process onboarding requests. It also provides visibility for tracking purposes, which is critical to HR departments.

What Request Management features are important to consider when looking for an enterprise solution?

Here are some of the key considerations to mull over when selecting a Request Management solution.

Select a Request Management technology that is:

• Agile
• Configurable
• Integrates with your existing applications
• Minimizes risk
• Scalable
• Self-provisioning
• Includes a workflow automation engine that enables complete workflow control

If you are looking for a Request Management application, a good solution to take a look at is Kinetic Request bundled with Kinetic Task.

Hopefully, this gives you a few things to think about when considering a Request Management solution for the enterprise. I’ll continue to dive deeper in my next blog.