How to Automate High-Volume Service Item Creation for Faster Service Catalog Deployment

The big challenge in the outsourced service provider world  (as well as for internal shared services groups) is quickly delivering customer value by offering specific managed service items faster and more cost effectively than competitors.  If  it’s taking months to on-board new customers and roll out new services, there is probably a competitor who can do it in weeks.  That cries out for an automated strategy of creating  reusable and transportable service items (prepackaged forms and processes) that can be deployed in any customer environment in a fraction of the time it once required to set up each customer’s system individually.

Fortunately, many of these services are similar from company to company and requirements are often well defined in spreadsheets and other formats. That makes automation a natural. The best way we know of to do this is to pump up with KURL.

Automated Service Item Creation with KURLKURL?  It stands for the Kinetic Uniform Request Language, which is a domain-specific language developed by Kinetic Data to provide an alternative approach to creating service items in Kinetic Request and Kinetic Task.  KURL works by parsing spreadsheet data or HTML code into KURL text files and then by executing that parsed data into KURL codes to automatically generate new service items for service catalogs.

In this manner, KURL can automatically generate thousands of service items defined in spreadsheets programmatically, as opposed to configuring services items individually.  It is especially useful when the creation of simple service items is driven by volume.  And because KURL files are portable, transferable and shareable from company to company and catalog to catalog, service providers can easily create large volumes of service items with automated workflows for any number of customers.

One large international electronics firm used KURL to create over 2,000 service items in just a couple of weeks.  Another Kinetic Data customer won a multi-billion dollar government contract by demonstrating how KURL could easily create customized service “storefronts” for multiple federal agencies.

What can KURL do for you?  Users tell us that KURL means:

•  Faster customer on-boarding for shorter time-to-value and higher customer satisfaction.

•  Higher profitability, since service items can be rolled out to multiple customers for a fraction of the cost of setting up customers individually.

• The ability to  deliver service items to industry verticals without requiring in-depth IT expertise.

And for internal shared-services organizations, an automated strategy using KURL can deliver higher demonstrable value to the enterprise by making service requests more easily and efficiently fulfilled.

Learn more by downloading this recent white paper on how to pump up with KURL.

How Innovating IT Practices Leads to Happier Employees

Everyone wants to work in an environment where they feel good about their jobs. And every CEO wants the organization’s employees to recommend the firm to others as a great company to work for and do business with. Now, findings from Forrester Research quantify the pivotal role that IT plays in supporting these outcomes.

According to Forrester, in companies where employees are advocates ” for their business as a place to work and as a place to do business,” 65% say they are satisfied with the service they receive from their IT departments. In contrast, just one-quarter of unhappy, non-advocate employees are satisfied with their IT groups.

How IT Innovation Leads to Happy EmployeesFurthermore, significant majorities of advocate employees:

  • Report they are satisfied that their IT departments understand their technology needs and what they need to be successful in their jobs.

  • Say they “have access to technology and tools to solve their problems and challenges.”

  • Feel encouraged to solve customer and business problems.

  • Are active users of collaboration and communication tools.

Clearly, as even Forrester points out, there are many other factors that affect employees’ overall work satisfaction and advocacy (corporate culture, policies, work environment,  compensation), but the correlation with IT support is nonetheless significant.

So how can IT managers help create a positive environment of employee advocacy? Here are three key tactics:

  • Help business managers use technology to automate common processes and solve business problems. Ideally, IT should provide departmental / business function managers with easy to use tools to create their own automated task workflows, with minimal IT assistance.
  • Give employees a single web (and mobile) portal to request any type of service. Ultimately, employees don’t care whether a specific request gets fulfilled by IT,  or HR, or facilities, or through coordination between different departments, and they don’t want to have to request different services from different systems and user interfaces.
  • Deliver services the way that users want them. Contrast the typical IT help desk queue approach with the user-friendly experience of Apple Genius Bars, particularly for remote users and road warriors. Enabling users to schedule an appointment online rather than wait in a queue, particularly for complex-but-not-urgent service requests, reduces stress for IT professionals and business users alike.

Trends like bring-your-own-device (BYOD) and an increasingly mobile workforce are creating new challenges for IT departments. But given their importance in employee satisfaction and advocacy, it’s crucial for technology groups to embrace new approaches that both enhance productivity and delight business users.

For more information, check our white papers Say Goodbye to the IT Service Management Queue and Business Process Automation Anywhere and Everywhere.

Going Beyond the IT Service Catalog

Fueled by ITIL recommendations, innovative vendor offerings, and industry analyst endorsements, service catalogs have emerged over the past several years as the preferred method for presenting IT services to users. Requesting “service items” like a new laptop, access to the corporate ERP system or printer maintenance is now commonly done through a service catalog application.

Some forward-thinking organizations have taken the service catalog concept beyond IT, extending it to include services from other groups like HR (vacation requests),  finance (travel expense reimbursement) and facilities (a new office chair).

Request Management Screen ExampleBut such extensions are often problematic and cumbersome, because service catalogs are often bolt-ons to core IT service management (ITSM) applications. Since these applications aren’t designed for general business use, it’s difficult for business function managers to define and tweak service item definitions and fulfillment processes without extensive (and expensive) IT assistance.

As a result, non-IT services are often presented to users via different systems (or at least different user interfaces), forcing users to learn multiple request systems and to know which to use for specific types of service requests. But business users don’t care which department is delivering a given service, or even if multiple departments have to coordinate tasks for fulfillment (such as onboarding a new employee). They just want it done, and they want it to be simple.

Consequently, industry analysts today say that “service catalogs” (an IT term) need to evolve into “request management” (a business term) systems. ITSM applications may still serve essential functions within the fulfillment process (along with HR, finance, ERP and other applications) but need to be coupled with a single, unified, user-friendly, web-based and mobile-enabled front-end portal: one request interface to use, any time, any where, for any type of service request.

Analysts refer to these as Systems of Engagement (the unified request management portal) for Systems of Record (the back-end ITSM, ERP, HR, finance and other apps). In other words, using a flexible, intuitive user interface to leverage existing investments in the enterprise applications which do the heavy lifting of service delivery, while shielding business users from unnecessary complexity.

In an enterprise request management implementation, service requests can be entered through a user-friendly portal interface (or triggered by events in other systems), with all subsequent tasks—approvals, scheduling, delivery, feedback collection, costing, and reporting—managed by an automated task workflow engine capable of secure communication with and between enterprise applications and federated data sources.

Business managers can create, manage and modify their own tasks with minimal IT involvement. The end result? A great concept—IT service catalogs—can be practically extended into any function in the organization, without an expensive and disruptive “rip and replace” implementation or any unnecessary complexity for department managers or business users.

To learn more, check out these white papers:

Agility is the Key to Request Management Software

Using Service Catalogs to Run IT As a Business (Not Like a Business)

Lessons Learned for Successful Request Projects – How to Scale the Heights of Success, not Plumb the Depths of Despair

It is rather surreal doing this blog post. I feel as if I am in a re-run of “Back to the Future.”

I am putting the finishing touches on this post before I present the session KEG, but because my internal clock is still set to Australian time, I am really doing it on the day after. These are some of the problems in living life “Down Under,” or as we Australians think of it, “Up Over.”

Australia- Up Over


Other problems include the “two nations separated by a common language”  that I encounter every time I visit. Please don’t ask me what team I “root” for or whether I would like to buy a Denver souvenir “fanny-pack.” Be careful asking me the way to the “bathroom” as it will get the response: “I’ve got a bath in my room, haven’t you?” We only have loos, dunnies, lavs, bogs or, if in polite company, toilets, and I take great delight in directing any American visitors to the room in my house that has only a hand-basin, shower and bath and not the other small room that has the toilet pedestal and watching their faces when they return with cleaner hands but a slightly more distressed look.

But enough of the cultural differences.

A little about myself and why you may be sitting in this presentation (if so, please put the iPad away and look at me) or reading this alone in your office or home (I assume because you have come to such a boring moment in your life when reading a blog entry of mine adds some excitement).

Well, I discovered the other day—through an automated message sent by our internal version of Facebook called Yammer (hopefully I get something for the plug—but not another bloody t-shirt please) that I have been with Kinetic Data (hereafter, KD) for over 8 years! That re-assured me, because I thought it had been forever…

I also have to admit that I am the oldest person in KD—but of course this does not mean that I am the wisest—as this blog post is proving!

Prior to KD—I can dimly recall that there was such a time—I have been with a number of IT companies working with BMC Remedy and other applications (they do exist), many of which have now melted away like the snow flakes which may be falling outside, when the sun warms them.

So, I hate to admit it, but I have been in this industry for over 40 years, so probably before most of you in this room or looking at this blog post were even in “project initiation phase” and probably before “requirements gathering” and putting out the “RFI or RFP.”

Since then I have worked as a Consultant, Analyst, Designer, Project Manager, Developer, Trainer and even once, on the “Dark Side,” as a Client in this industry of ours.

So, I think I have a right to have a few opinions on this whole “Requirements” business. Hopefully these opinions will inspire some thought, maybe even controversy, and hopefully someone might feel interested enough to have bought me a drink (Single Malt Scotch over 12 YO) to get me to share a little more of my “wisdom.”

OK—here we go.

I was told my Power Point did not have enough bullet points, so I added a second Agenda page. Apart from these two pages, there will be:


This achieves two things: 1) you might listen, and 2) I don’t have to think of another way to say the same things without using the words in the bullet points.

(For those reading this blog, who want to look at the pictures, someone will have posted my presentation somewhere on the KD website—so you could download it and enjoy the full experience of course, without the “gosh I like the way you Aussies speak” audio component.

Let me “share with you” my first EDP (look it up) job, programming a door opener. I got paid about $50 for it (in those days that would be USD25—now it would be USD60—how the weak become the strong). After the stunning success I had in fulfilling the requirements—door must open, door must stay open for a while, door must close—the requirements were expanded to encompass the concept of “small room – moving up and down in a controlled way,” so I programmed a bigger controller that incorporated all the great work I had done with the  “Project Door” and added moving a room up and down in a vertical shaft, stopping and then doing the door bit. We called this “Project Lift”—or in American—”Project Elevator.”

This was the first time I had been confronted with the idea of requirements analysis in the “real world.” I was obviously excited.

They were simple requirements. We did have a discussion as to whether the doors should open in an “organic, caring and cool way”—it was the 70’s—but we knew that person was a closet hippy, so we ignored this suggestion and just went for “slamming open and slamming shut.” A lot of people nearly lost limbs because of this —but I had the cheque (check) and had moved on to bigger and better things like the Traffic & Parking Infringement Notice system for my home state (Australians have the same urge to make an acronym of everything—that is, when they cannot add an “ie or y” to a name—and we called it the “Project Tin-Pins’.” Yes, there were nerds even in those days and we were they.)

So that brings me to the point of the is session.

How to achieve a successful Kinetic Request project—and—taking a leaf from the “Self Help and Actualisation Movement,” or as I like to call it, “SHAM”the path to success is:

Achieving Oneness with Request ManagementONENESS…

Normally the first interaction you have with any vendor is through the sales team.

Sometimes the interaction is like this…

Over-promise…Get the deal…Under-quote…Under-resource…Under-deliver

At Kinetic Data, we try to make sure that we do not do that.

At the heart of achieving this is ONENESS between the client and Kinetic Data.


Without clearly stated initial requirements everyone is working in a fog of doubt and uncertainty.

Vendors build-in large buffers for this uncertainty and often still under-quote for the project.

Once you have decided on a vendor for your project, work with the internal and vendor teams to:


Things to consider when doing this:

  • You may not have all the information; consult widely with ALL stake-holders.
  • There is only  piece of clothing where “ONE-SIZE-FITS-ALL”—a straight-jacket.
  • Trying to combine features of different offerings is rarely a success.
  • Just because it can be done, does not mean it should be done.
  • It may be a solution—but is it practical?

There is a reason why you are initiating this project, and it normally not just to:

  • Replicate the existing application
  • Change the appearance slightly
  • Bolt-on some new functionality
  • Get a more powerful application but restrict it to the old limitations

A successful project should deliver improvement. Not repackage the status quo!

To achieve this, all the parties have to be able to be flexible and willing to change expectations and requirements to deliver the BEST solution within budget and on time.


Be realistic. Rome was not built in a day.

If you have been set firm dates  and budget to deliver, then make sure that the requirements are aligned.


We are now in partnership with you to deliver SUCCESS.

It is not a battle between two sides—one trying to get more than agreed and the other trying to do less.

Remember that in a difference of approach, the consultant will advise on the best solution, but at the end of the day—if the client wants it, we will build it.


So we now have a project that has REAL, WELL DEFINED and ACHIEVABLE requirements.

So, let’s stick with them when we develop the SOW and during the delivery period.

Tacking on new requirements while development is going on does not work. It adds to costs and delays.

Importantly, it just shows that the requirements gathering was a failure.

Finally, remember the ultimate measure of success is the satisfaction of your users.




How to Create a Consistent User Experience (And Why You Should)

What makes Facebook a success?

Obviously it provides a way to communicate with friends and acquaintances; but it’s unlikely it would have been as successful if it had followed the design methods that can be found in too many corporate intranets.

One of Facebook’s major features is “consistency.” Consistent styling; consistent behavior; consistent look-and-feel.

Consistency is paramount to the success of all successful social networking sites. In fact, consistency is such a hallmark of these sites that ANY change to the design makes headlines or at least millions of wall posts!

But even when Facebook does introduce updates and new features, it keeps enough of the fundamental functionality and navigation consistent that users are able to fairly easily roll with the changes.

Consistency and ease of use have driven Facebook’s success. From the beginning, the company knew it wouldn’t be able to scale rapidly if it had to hire a huge support team to help users utilize the site. (Ever tried to reach human support on Facebook? Good luck.)

So they focused, relentlessly, on keeping it simple–so simple that even grandmothers (and grandfathers) with almost no computer experience could figure out how to create a page and share photos of their grandchildren.

The Challenge of Simply UI DesignBut if Facebook was like most corporate intranets, its doubtful users would have returned again and again.

Corporate intranets too often present different styling, navigation and features across different applications, sections and pages. Users experience a chaotic environment where they have to work at navigating through the site. Inconsistency causes confusion for users and results in incorrect choices and incomplete responses and general frustration. In a request fulfillment environment, this results in reduced usage and an increased need for ‘call-back’ from the fulfillers.

Consistency Not Chaos

The example below (one of the standard templates provided with Kinetic Request) illustrates a better approach: consistency, not just in styling but also in navigation and layout. From page to page, navigation elements and “action” links remain in consistent locations.

Consistency and clarity result in higher user adoption, faster service request processing, and smoother workflow for service delivery staff.Request Management Screen Example

With a clear and consistent design, users should be confident after the first page of a number of vital things:

  • Where to expect to find information
  • How to navigate from the page and back to the page
  • How to leave the page
  • How to get more information about an item
  • How to select an option or item

Even complex forms can be simplified by pre-populating fields with known information (e.g., if the user is logged in, the system should already know the user’s name, title, office address, phone number, email and other similar data) and keeping the layout consistent with other pages while removing unnecessary information.

Elaborate Yet Simple Request FormQuestions should be “nested” so that additional questions are revealed only if and when the added information is required.  Complex instructions can be avoided by clear and simple navigation that is consistent between forms.

Consistent site style provides a number of benefits for users: it’s easier to use, more predictable, and speeds the request-to-fulfillment process by avoiding unnecessary support phone calls and clarification emails.

In addition, consistent design benefits the organization by:

  • Controlling ‘rogue’ development
  • Enhancing corporate identity / branding
  • Lessening “silo” effects between departments
  • Unifying fulfillment – especially when it is multi-faceted

This post was based on the presentation “Creating Consistent User Experiences” delivered by Michael Poole and Shane Bush at the 2012 KEG event. You can view details of the original presentation on Kinetic Community or learn more about the upcoming 2013 KEG event.

The Benefits of Bundled Service Items

What exactly are “bundled service items” and how can they help your business? To answer the first question first, bundled service items are simply a group of individual service items that are linked in some fashion.

The benefits are many, and depend on the type of bundling, the nature of the task, and the specific service items in the bundle, but often include reduced time, better documentation and reporting, development of more efficient processes, more consistent follow up, improved user experience, simplified approval processes, easier maintenance, and improved business results.

A few examples will help to illustrate, but first some structure. There are three different types of service item bundles that can be deployed, depending on the nature of the high-level task:

  • Linking refers to chaining different service items together. It works well for processes that require phased approvals or multiple steps, each requiring separate information and often involving different users.
  • Embedding means a situation where one or more service items are initiated as part of another service item. This works best for complex, multi-step processes where each service item could stand alone but embedding the items provides a better user experience. Embedding service items also normally results in faster delivery of the entire process.
  • Grouping is when unrelated, stand-alone service items are correlated only because of who completed them or when they were requested, that is, when unrelated items are grouped for a business reason. The simplest example is an online shopping cart; two (or more) items that are completely unrelated may be bundled using grouping only because they are placed in the same cart.

Linked Service ItemsOne simple example of linking would be a work-from-home approval process. Without applying service management principles, the process is likely to be informal, ad hoc and inconsistent, with no documentation or structured measurement of results.

The bundled service item method would simply entail linking three service items—request authorization, request equipment, and schedule performance evaluation—in a new process.

Once authorized, the user could be prompted to order equipment, acknowledge specified company policies, or take other actions. The process can be configured to include a “wait cycle” before the first evaluation; but at the end of that time period, the evaluation is automatically triggered. There is no “dropping the ball.” Depending on the results of the evaluation, the worker may be authorized to continue working from home or a “discontinue working from home” process could be initiated, including the return of any checked-out equipment.

Embedded Service ItemsAn example of using embedded service items could be in employee onboarding. Without a firmly defined activity flow, the onboarding process can be chaotic, complex, inconsistent, inefficient and frustrating. A better approach is to create a single service item that “contains” the overall process, and consists of many nested, embedded service items that deliver the results. This simplifies what can be a very complex process.

In this embedded service item structure, the container or “parent” service item contains overall process details and common elements (e.g., employee name) applicable to every “child” service item; these child items handle the unique details of each request. Child service items are completed within the task tree of the parent.

Once created, the onboarding template can easily be cloned and have specific items changed or swapped out to accommodate bringing on employees in different locations, functions or levels of the organization.

Finally, a common example of grouping, as noted above, is online shopping cart functionality. Without the ability to bundle service items in this manner, an employee may have to “buy” service items in the equivalent of a shopping mall, going to different departments for different items, each with its own “checkout” process.

But using grouped service items is more like shopping at the supermarket; the user can place different service items into an online shopping cart and “check out” all at once. Even though different approvals may still be needed, these are routed automatically at the end of the process to their appropriate destinations; this is transparent to the user, creating a faster and simpler user experience.

Bundled service items are typically deployed as a process. All that’s needed is creativity (think about the objective to be achieved or process to be re-organized), bringing together the right group of people (users, approvers and other stakeholders) and then creating the workflow that bundles required processes to automate, simplify and accelerate.

This post was based on the presentation “The Impact of Bundled Service Items” delivered by Kinetic Data consultant Matt Howe at the 2012 KEG event. You can view details of the original presentation on Kinetic Community or learn more about the upcoming 2013 KEG event.


What is this “Level 0” thing? (Part 2): Knowledge, Self-Analysis and Feedback

Tools of the Trade (Part 2)

A Vision From Down Under
By Michael Poole

In my last blog, I mentioned a major client who is ‘shifting to the left’ and implementing ‘Level 0’ methods.

For those who missed my last blog, in short, ‘Level 0’ is the process of enabling users to resolve their own incidents and requests.

Obviously, one way of implementing ‘Level 0’ is to shut off the phone lines and email addresses of the Help Desk. A very effective way of getting users involved in the process, but not one I would recommend to anyone wanting a long future in an organisation. Of course, sometimes we implement this method by under-resourcing our support teams – but that is the subject for another blog.

To implement ‘Level 0’, users have to have the information available to them to resolve issues as they arise. So how do we give these to them.

There are a number of tools available.

The Knowledge

It has been famed around the world that London cabbies spend years “doing the knowledge” — learning every street, lane, theatre, hospital and pub in London — before they can sit for the exam to obtain a cab licence. Do we need to ensure that before any person joins the organisation they have an intimate knowledge of computer hardware, software, networking etc.?

No, because now, they can be like today’s Sydney cabbies who avoid “the knowledge” by having a SatNav or GPS system in the cab. Our users’ SatNav can be a Knowledge Base.

The move to implementing “KCS” or Knowledge Centred Support has been going for a number of years, but for many organisations, this has been limited to building knowledge bases directed at and only available to the support team — not the user. With the development of Web 2.0+, users are becoming more accustomed to “googling” for solutions and answers and also using self-help resources that are a part of the major social media sites. I admit, in doing these blogs, I have often consulted the blog site’s help pages and Support Forums.

So KCS is one of the tools that can be deployed as part of the “shift to the left.” But to do this, we have to make sure that we develop our KCS articles, not for computer engineers, or if we are deploying across an enterprise , HR experts or accountants etc, but for the average user and common issues.


No, I’m not becoming Tony Robbins — all “SHAMish” (Self Help and Actualisation Movement) — perish the thought — or bringing Freud onto the Help Desk — even though at times he might be useful in dealing with users, but more IKEA!

The results of some IKEA assembly projects might belie the concept — but I assume that they have more successes than failures through the step-by-step self-assembly process.

A few — well maybe many — years ago, I was involved in a project that required me to have what is called an “Assumed Rank” in the Australian Armed Services. I made Colonel for a month — the duration of the contract — but thankfully did not have to do the physical, wear a drab khaki uniform, bear arms or be saluted. But I did get into the Officers’ Mess and people had to answer my questions in a respectful way, but that is past. What I did get to find out was how the most complex maintenance and repair processes for a fighter jet could be broken down into simple steps and documented so that even I could have replaced, as an instance, the wiring loom on an F-111 or the laser-guidance system. The “repair manual” — and it was all hard-copy — was contained in a room-full of filing cabinets and needed a librarian to keep it in order and up-to-date. This of course was an extension of the production line methodology introduced by Henry Ford at his eponymous company to make the most complex consumer engineering  product of the day — the motor car — with relatively unskilled workers. Other car makers of the time were using skilled engineers and coach-makers to make one car at a time.

As the makers of the F-111 and Henry Ford knew, every process can be broken down to simple steps and delivered in an appropriate way to produce a complex result. For Ford this was a car; for General Dynamics it was the F-111 repair manual; for us this can be a fault-finding and resolution process.

In fact for the client mentioned above, we implemented such a system — a fault-finding process that enables staff with little or no technical knowledge to analyse and, in over 30% of cases, resolve issues with lap-tops ranging from OS to wireless network issues through a series of simple steps that relied on the answers to a number of questions and test activities that they could understand and carry out.

So another tool in the “Level 0” process, is intelligent and responsive self-analysis and resolution tools. What is sometimes called an “expert system.”

Information, Contribution, Monitoring & Feedback

Implementing “Level 0” also requires openness of information and a positive response to user feedback.

Users should be given every opportunity to be a part of the process.

Where KCS is implemented, users should be able to rate and suggest improvements to KCS articles and guides and also author and submit new KCS articles. As well as providing another source of input into the KCS system, users will develop a group ownership of the KCS system and its acceptance will be more easily gained.

This is also true of any self-analysis and resolution process. A network engineer may be able to define the step-by-step process for resetting a head-end switch, but it may take some input from an end-user to enunciate the process in easily understood vocabulary or point out areas that need better definition.

Users must also be contribute to the areas that need to be covered in the KCS or self-service system. What the experts think are trivial matters, may be a source of confusion to users.

Access to monitoring information in a easily understandable format can reduce calls on the Service Desk. If users know that a system is down for maintenance then they have no need to log a call.

And of course feedback to users is essential when they make a contribution or highlight an area that needs better coverage.

In part 3, I will look at ways to integrate these tools into web-based portals that can be deployed to users.





The ABCs of Request Management

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.

Request Management DiagramWhat’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.