The Evolution of the Service Catalog – Here’s What Comes Next: Forrester Research, Part 1

The concept of the IT service catalog isn’t going away but it is evolving. As a caterpillar turns into a butterfly through metamorphosis, so the IT service catalog is being transformed. It will emerge in forward-thinking organizations as a higher-level entity called the business service catalog.

That’s one of the core takeaways from Master the Service Catalog Solution Landscape in 2013, a Forrester Research white paper. Authors Eveline Oehrlich and Courtney Bartlett introduce the white paper by stating that, “The successful IT organization no longer just keeps the lights on—this organization enables the business to achieve organizationwide goals. To facilitate this shift, IT organizations must now focus on…delivery…of services rather than IT technologies. To do this you must have a service catalog.” But most current IT service catalogs, focused on descriptions of services IT offers to the business, are inadequate to this task.

As IT moves from a supplier of services to playing a more central role in driving business initiatives and success, its mission must shift from information technology (IT) to what Forrester terms “business technology” (BT). “The shift from IT to BT requires new models for how technology is delivered, operated, and supported. Services must be defined, and there is no right or wrong way to do this.” (Though there is a fast way, as previously described here in How to Automate High-Volume Service Item Creation for Faster Service Catalog Deployment.)

Furthermore, per the authors, “Forrester believes services should be primarily defined from a customer point of view,  or with a particular business outcome in mind. As IT moves from being a provider of technologies to a broker of services involving technology, a comprehensive service catalog becomes imperative for the health and future of the business.” In other words, the BT vision means extending the service catalog beyond IT to encompass services provided by departments and functions across the organization.

Forrester Research Employee Onboarding ModelFor example, the figure at right shows a simplified list of services associated with onboarding a new employee. Most of the services shown are provided by IT. The goal of employee onboarding, however, is to get new employees productive as quickly as possible; ideally, new employees would have everything they need in order to do their jobs at their fingertips on their first day. This holds not only for new employees, but for those transferred to a new role or new location as well.

The image below shows an example task tree for an employee onboarding process: not only the different departments involved (IT, facilities, HR,  etc.) but also the multiple approvals and fulfillment actions required to fully provision a newly hired employee.

Employee Onboarding Process Task TreeForrester’s BT vision thus nicely correlates with the concept of enterprise request management (ERM). The business service catalog must be actionable (not merely defining services); it must extend beyond IT into services delivered by other functions (such as HR and facilities); and it must be capable of managing complex processes spanning multiple departments and business functions—while shielding the business user from that complexity.

Part two of this series will detail the benefits of undertaking a business service catalog initiative, and part three will outline the architectural requirements.

For more on this topic:

Six Steps for Choosing the Right Business Process Software Tools

You’ve identified a broken business process. Now—do you need to invest in new technology to fix it? Or just to re engineer the existing task flow? Or both?

That line of inquiry is fundamental to the recommendations presented in the white paper Process and Tool, Chicken and Egg: Finding the Right Tools for Your Organization,  in which author Roy Atkinson of HDI outlines six key steps for selecting new technology tools.

How to select software toolsIf new technology is needed, the six key selection steps specified in the white paper are:

1. Get the right people involved.

The first step is among the most crucial. Staff members at different levels and from different departments each bring unique perspectives to the table. One key function of the group will be to produce financial justification. As Atkinson points out, “Business leaders will want to know the value that any change will provide, especially when it will require a substantial investment of money, resources, and time.”

The process used to calculate the cost savings and ROI from automated self-service can serve as a useful template for calculating the value of a process change or technology purchase.

Involving the “right people” extends to finding the right management sponsor. Atkinson notes, “When looking for management sponsorship,  be sure to consider the amount of change your initiative will require. As the saying goes, ‘Culture eats strategy for lunch.’ Entrenched behaviors can erect barriers at every level. You’ll need someone to help overcome this resistance.”

One way to address the resistance issue when implementing a significant operational  change, such as implementing an enterprise request management (ERM) strategy, is to proceed in small, incremental steps. Focus on achieving a series of “small wins” that prove the value to all stakeholders and minimize the fear of change.

2. Ask the right questions before you start.

Among the most important questions to ask, according to Atkinson, are: what problem are we trying to solve? And why do we need new software tools?

He continues, “If the answer is ‘our tool doesn’t do what we need it to do,’ then you need to lay out the unmet needs carefully and completely so that you don’t make a mistake when you buy new technology.”

It’s also vital to clarify whether you really need to do a major “rip and replace” type implementation, or if needs can be met with a simpler tool that leverages and extends the value of your existing enterprise software investments.

3. Define your processes before searching for tools.

Before even beginning a search for suitable software, it’s vital to have your team of “the right people” define what an “un-broken” process would look like. The best approach here is to heed the advice of Stephen Covey to “start with the end in mind.”

The desired end result of any type of service delivery process, for example, should be to have a delighted customer. The redesign should therefore proceed from that perspective: how would this process work in a way that is ideal from the standpoint of the end user; how can we make it better, faster and cheaper for both the (external or internal) customer as well as the organization?

Atkinson advises asking not only about end goals but also about the gaps between the current process and the desired one. “This gap analysis can point out where you can best leverage technology, and where you can make changes to current processes and procedures to achieve your goals.”

4. Find the hidden expenses.

Hidden expenses include gaps in skills that will need to be met with training; the need for outside talent, such as business or technical consulting; and the costs of software customization.

The last item above can be addressed by seeking out software that is configurable rather than customizable (configuration changes are generally more like to survive version upgrades than are code customizations), or by looking for tools that can be customized at the user interface level (systems of engagement) rather than requiring code changes to underlying enterprise applications (systems of record).

5. Decide whether or not to customize.

Should we customize our processes to fit the software, or customize the software to fit our processes? It’s hard to admit your baby is ugly, but the fact is that most enterprise software is designed to support industry “best practices.” If your processes are less efficient than those of the leaders in your industry, then your processes need to be adapted to at least that level. But your baby may not be ugly: if your process is actually more efficient that what the software would dictate, customizing the software is definitely in order.

Bear in mind there will be costs either way. As Atkinson puts it, “Customization can be very expensive, but large organizational changes are themselves not inexpensive.”

6. Have a plan for measuring success.

Again, before implementing any new technology, methods for measuring the results of the change need to be identified. Ideally, the software itself will provide analytics that help quantify results.

For operational purposes, you’ll want to track metrics such as time saved, manual steps eliminated, support calls reduced, and user satisfaction increased. Upper management, however, will need to see these improvements translated into dollar terms. The labor cost savings in eliminating a call to support should be easy to track, but it may take more creativity to quantify the savings from greater user satisfaction. Does it help to retain customers who may otherwise have been lost? Increase revenue opportunities? Prevent people from getting frustrated and “going around” the system, saving those attendant costs?

Overall, as Atkinson notes, these steps aren’t designed to help choose from among competing software applications, but rather to provide a solid foundation for improving business processes and determining what types of technology tools, if any, are need to support that improvement.

For more on this topic, check out the white papers Enterprise Request Management: An Overview and Agility is the Key to Request Management Software.

To follow and contribute to the discussion, join the Enterprise Request Management Group on LinkedIn.

Four Ways to Make Business Processes Better, Cheaper AND Faster

You may have seen signs like the one below in different types of repair shops in years past. Some rural auto garages still sport them.

But as the authors of the white paperHumanizing Business Process Automation point out, customers (internal or external) no longer accept the “pick two out of three” perspective. They expect it all. And there are almost certainly competitors of your firm working to deliver on those expectations.

Making business processes better, cheaper and fasterHow can businesses provide outcomes that are better, faster and cheaper all at once? The white paper’s authors, Jesse Clark and Rachel Wentink, write that “Business process automation (BPA) software can improve quality, reduce manual effort and accelerate processes, which are at the heart of good, fast and cheap.” Then they add: “However, software is a tool, not a magic bullet.”

Clark and Wentink proceed to outline four key approaches, all of which are components of the enterprise request management (ERM) framework. Reordering their list just slightly, and expanding on their points, the four approaches are:

1. Reverse engineer your process: start with the result of a delighted customer. Simply using technology to automate poorly designed business processes merely enables you to do the wrong thing faster. Before automating anything, take a step back and redesign processes to be ideal from the perspective of the customer (again, internal or external). Then map and automate that process flow (i.e., make the process better, then faster).

2. Lighten the labor intensiveness. This is accomplished in ERM by automating manual approval, scheduling and service fulfillment processes through software wherever possible. Automation reduces costs and accelerates service delivery processes (i.e., cheaper and faster).

3. Reduce mistakes or fix them quickly. Mistakes are often introduced into business processes through redundant, manual data entry. Minimizing the amount of manual data entry required, asking for each piece of required information only once, and validating all data at the point of entry reduces effort and errors (i.e., faster and better).

4. Take an evolutionary approach to process improvement. Within the ERM framework, both quantitative (e.g., time to complete a task) and qualitative (end user satisfaction with the completion of that task) data are collected and reported for analysis (providing information on how to make processes faster and better).

Contrary to the goal of delighting the customer, the authors note that “the primary customer service business strategy for many firms is reducing costs. Instead of leveraging the voice-of-the-customer to fix process problems and build customer loyalty, the firm accepts that customers will have unmet needs, experience problems, and encounter difficulties in doing business,” despite the fact that “study after study presents compelling evidence that long term success is driven by the ability to have happy customers.”

The analytics built into ERM help to continually improve processes once designed, but how do organizations develop customer-centric processes in the first place? Clark and Wentink advise, “Choose a process that’s broken…envision how you would change that process to have a delightful outcome. Focus on the desired outcomes and map out the necessary people, functions, workflow, data, and timing required to achieve the outcome. Leverage the (BPA) tools to communicate the process and use this to drive the necessary organizational changes and technology support.”

A key strategy for reducing both labor intensiveness (either on the part of a service desk representative or the customer) is to simplify the data entry process by pre-populating as many fields as possible. If the employee or customer is logged in, or the system knows some uniquely identifying piece of information about that person (e.g. an ID number), then there’s no need to ask for basic information like name, address and phone number. At most, the employee/customer can be presented with the pre-populated fields and asked to confirm or correct the information.

This is a “three-out-of-three” improvement; it reduces costs (by saving data entry labor), saves time (by requiring less of it to complete a form) and improves quality (by virtually eliminating manual data entry errors, as well as making the experience more pleasant for the customer). Cheaper, faster, better.

Automating common tasks like sending emails requesting approvals—and sending follow-up reminder emails if necessary—also ensures the integrity of processes while saving time and costs by taking the process management burden off of employees (or worse, customers) and making machines do the work.

In short, ERM and BPA can enable organizations to move beyond the “good, cheap, fast: pick any two” mindset and delight customers (while reducing costs) by delivering all three benefits.

To learn more, check out the white papers Enterprise Request Management: An Overview and Business Process Automation Anywhere and Everywhere.

And to keep up with the latest developments, join the Enterprise Request Management Group on LinkedIn.

How to Calculate the Cost Savings from Automated Self-Service

It’s not unusual to find large organizations still using manual processes for service delivery. Users fill out a paper form, fax it to a service desk number, then follow up by phone or email to check on the status of their service requests. This approach requires many inefficient, manual tasks in the service fulfillment process.

What many organizations want—and are trying to move to—is automated self-service for requests, with a single intuitive interface through which users can find any type of service, make a request, and get the service delivered with no manual interaction.

In this model, key tasks such as scheduling, approvals, costing and reporting are automated–accelerating the delivery process, improving accuracy, and reducing costs.

Requests are made through a web-based, mobile-friendly portal that requires no training to use. The portal also provides visibility into the delivery process, eliminating phone calls and email messages to check on the status of the request.

Benefits of this approach include:

  • faster service delivery;
  • a better user experience; and
  • a more effective, lower-cost process for delivering services.

Calculating the return on investment (ROI) start with an evaluation of the time spent requesting and delivering services under an organization’s current approach. This is then compared, on a per-request basis, to the time requirements under an automated enterprise request management (ERM) approach, including total cost of ownership for the new system over three to five years.

ROI is the cumulative cost savings across all services that can be automated divided by the total costs (software, hardware, services, implementation, training) of moving to an ERM approach. The total business impact varies with the volume of service requests which are candidates for automation.

To learn more about the ERM approach to automated self-service, download the whitepaper Enterprise Request Management: An Overview.

How Forrester’s Smart Process Apps Fit with Enterprise Request Management

Forrester Research recently published a report titled Smart Process Applications Fill A Big Business Gap. The title is certainly apt, since smart process apps as Forrester defines them are essentially specific business process workflows modeled in an enterprise request management (ERM) framework.

The analysts define smart process apps (SPAs) as “a new category of business application software designed to support processes that are people-intensive, highly variable, loosely structured, and subject to frequent change. Smart process apps fill the gap between systems of record and systems of engagement by automating both structured and unstructured work activities in support of collaborative processes.”

Task Map for an Employee Onboarding ProcessBreaking that down, an SPA is essentially software “plumbing” that enables functional department managers (in IT, HR, facilities, accounting, operations or other areas) to define business process flows, then manages those flows to accomplish a specific task (which can be as simple as changing a user’s security access settings or as complex as onboarding a new employee).

Because such processes are “subject to frequent change,” the SPA must make it easy to modify existing workflows as well as create new ones. Because the processes are collaborative, the SPA must be able to communicate with and between people through “systems of engagement” (online forms, intranet applications, or request management software like Kinetic Request) and “systems of record” (federated enterprise systems such as ERP software, financial and reporting applications, HR suites, email systems, etc.).

The Forrester report further states that “SPAs increasingly incorporate BPM (business process management)…mobile development frameworks…(and) business rules package integration”—all of which sounds much like the Kinetic Task workflow automation software engine—as well as “complex event management” (a function of the Kinetic Calendar online calendar tool).

Among the characteristics of such software, the report authors include, “SPAs make processes easier for employees to comprehend and interact with.” Within the context of ERM, the software should enable employees to not only easily request a business service but also to monitor the status of that request (much like online package tracking offered by major shippers); it should also make it easy for managers to create, review and adjust the processes required to fulfill the service request. In addition, SPAs will incorporate “advanced analytics (that) deliver just-in-time insight within context.” In an ERM strategy, the underlying system collects and reports on metrics regarding process and sub-task completion times and costs to support continual improvement.

Finally, the Forrester report predicts that “The next generation of packaged process applications will encapsulate…process models in these collaborative business processes yet make it possible for business people to modify the app to reflect continuous improvement in how collaboration, engagement, and interaction can occur.” The “next generation” of applications may or may not do these things—but Kinetic Task does much of this today.

Want to learn more? Download this white paper on our approach to enterprise-wide holistic  business process automation (BPA).

Upcoming Webinar: The Enterprise Request Management Approach to Reducing the Cost of Service Delivery

In survey after survey conducted by leading business publications and analyst firms, executives consistently rank “making business processes more efficient” and “improving the customer experience” among their top priorities. Yet organizations continue to struggle with inefficiencies and customer satisfaction issues.

Business process automation (BPA) software can help–but it’s only a tool. If processes themselves aren’t engineered to optimize the customer experience, the result is simply that broken processes get completed more quickly. Enterprise Request Management (ERM) is a strategy geared towards improving service, while reducing the cost of delivery in an scalable and risk-managed approach.

What’s needed is a different approach to managing service requests and delivery, an approach that:

  • makes it easy for customers (whether internal or external) to request services of any type from a single, intuitive interface (with the simple elegance of websites like;
  • enables business managers to define and continually refine their own automated processes and task workflows, with minimal assistance from IT;
  • leverages investments in existing enterprise software systems and federated data sources–while hiding the complexity from users; and
  • automates approvals, scheduling, costing, and reporting to support continuous process improvement.

You can learn more about the ERM approach in the upcoming webinar on May 22nd at 2:00 EDT. If delighting customers while decreasing service delivery costs sounds appealing, register for this webinar today!

How to Drop Notes without Missing a Beat

Lotus Notes is a venerable product with more than two decades of development behind it. But for many of our current and prospective customers, the product has run its course.

Several large enterprises, with dozens of Domino servers, hundreds of Notes databases, and thousands of Notes applications between them have directives in place to move off of Lotus Notes, but are looking for alternatives to spending thousands of person-hours on large porting projects.

Lotus Notes migrationFor many companies seeking to move away from Notes, Kinetic Request is a promising alternative. Though Request doesn’t duplicate all of the functionality of Notes, it can be used to rebuild business applications—often in much less time than with alternative approaches. For example, as noted in a previous post here last summer (Lotus Notes Apps Find a New Home in Kinetic Request), one large financial services company moving off of Notes rebuilt two critical business applications in less than 400 hours using Kinetic Request, versus the 2,000 hours it had estimated for custom development.

Compared to Lotus Notes, Kinetic Request is:

  • Built for the web;
  • Built to incorporate federated data (data from virtually any enterprise data source); and
  • Built with APIs in mind.

What’s more, Kinetic Request coupled with Kinetic Task provide the front-end and the backbone for an enterprise request management (ERM) strategy, in which virtually any type of service request (whether from human resources, IT, facilities, marketing, accounting or another function) can be entered in a consistent, user-friendly web portal with all subsequent approval, scheduling, and fulfillment tasks fully automated and tracked.

Many organizations using Notes may be comfortable staying with the platform indefinitely. But for those committed to making a move, Kinetic Request may provide a rapid and cost-effective method for rebuilding key business applications.

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.