Process Work v. Knowledge Work – The Emergence of Performance Management

By now, those of you who’ve read my previous blogs realize I tend to only post something when I think I have something interesting to say. Unfortunately, the empirical data suggests that this doesn’t occur with great regularity! It’s my hope, though, since you’re investing your valuable time reading this that I am providing something useful to you.

With that, here are my latest thoughts that pertain to ‘process work’ and ‘knowledge’ work and why I think the software industry has done a reasonable job addressing the former and has until recently let down the latter. Let’s start out by defining the two terms.

I define ‘process work’ as those sets of predefined actions that a person must perform in order to accomplish a business task. These include things like: placing an order, posting a transaction to the general ledger, entering a customer’s contact information.

I define ‘knowledge work’ as relatively non-linear actions that a person must perform in order to solve a business problem. Inherently, these involve answering questions rather than performing step by step actions and include things like: figuring out what my target commit number should be for the forecast, what guidance should I provide to Wall Street, are my operating costs optimized, etc.

With process work, integration is typically peformed through a software backplane or bus. With knowledge work, integration is typically performed through the cerebellum.

We (that is, the application/business software industry — SaaS or otherwise), have done a reasonably good job over the years providing solutions to support ‘process work’. However, we have generally done a terrible job of providing solutions to support ‘knowledge work’.

If I work in a call center as an agent, in the accounting department, or in sales operations and if I live in a software application to perform my job the majority of my workday, the chances are great that the software I use has evolved to a point where it works well for my role. Even if I don’t necessarily love the user interface and complexity, I get familiar with it and over time I can become proficient with it.

However, if the majority of my job is being a sales manager, sales representative, or other field work of any kind and I am just a “drive by” user of application software, the chances are great that the software does not work well to address the business issues I am concerned with.

One of the reasons we had great adoption by sales operations, call centers, etc. at Siebel Systems and low adoption by sales executives, managers and representatives is directly related to the fact we built a system to handle operations/process sales transactions but we did a relatively poor job (until we introduced Siebel Analytics) of providing Sales management with solutions that addressed their function.

SaaS is not the sole answer here. Informal market survey data suggests that Salesforce.com has not done much better than Siebel in terms of true end-user adoption by the Sales organization (Don’t believe me? Ask a bunch of field sales reps in a company using Salesforce.com how much they really use the application). Its appeal has largely been due to the fact it is a much lower cost alternative to Siebel’s on premise solutions and there is no requirement for IT to be involved in the configuration, implementation and management. Want more proof — in spite of Salesforce.com’s impressive growth in the mid-market and divisions of enterprise sales organizations,  Siebel/Oracle continues to own the call center – a highly process-oriented, IT supported function – and it is highly unlikely to be displaced there anytime soon by Salesforce.com.

To address the issues related to knowledge work, a new class of application software has emerged into a category now labeled “Performance Management”. These are applications built on top of analytical and transactional systems and are designed to address the function of knowledge work. Originally, these solutions started in the Back Office (e.g. F&A) with companies like Hyperion who wanted to help the CFO be able to better model, plan and compare budgets, forecasts and perform consolidations.

Now, however, Performance Management is moving into the Front Office (e.g. the Line of Business owners in Sales, Marketing, Service, and Support). For example, if I am a VP Sales, then I want to be able to better predict and control my forecast, if I am a VP Marketing, I want to better be able to predict and generate lead production.

One of the key challenges of making these new Performance Management solutions successful in the Front Office is that the periodicity of change is much greater, therefore the delivery model must not be tied to IT (e.g. it must be SaaS-based) and the user interfaces that have traditionally served the Back Office/Process Work side of the business (master-detail lists/transaction oriented) must be substantially modified and improved in order to gain widespread adoption and use.

I will give you an example of where this is going. One of my portfolio companies, Right90 (www.right90.com), started out as a SaaS-based  “Sales Forecasting” company targeting Sales Operations. Today, it has been repositioned as a Revenue Performance Management company focused on providing Sales Management and Sales Operations with the ability to much better plan, model and predict revenue. Since making this transition, the company has experienced very good growth.

Before they could accomplish this repositioning, however, they needed to develop a different type of UI. A UI that better fit the needs of the Sales, Products and Channel teams that are responsible for managing revenue/forecasts. What did they come up with?

I’m sure you’ve seen those desktop stock widgets where you can have your favorite stock index and/or stocks on your desktop. And, as the markets move up or down, you can tell immediately (well, 20 minutes delayed) how they are reacting because the color of the widget changes from red to green or vice versa. Additionally, they tell you how much they’ve moved. If you want to know more, you click on the widget and a window opens up displaying a chart of the stock price over time and the stock volume over time. Other information about the company (e.g. press releases, industry analyst data) is also displayed.

Imagine using that same metaphor to relate the forecast throughout the organization. As the forecast changes over time, the widget changes red/green to connote status against targets. And, since it is “role-based” each team/organization sees just the information it is entitled to see. The CEO, CFO and VP WW Sales see the aggregated data. Who’s on plan? Who’s dropped their forecast? Is the company on target to make its revenue objectives? All of this can be easily pushed to everyone in the company who has a need to know, in realtime. You don’t have to remember to log in or wait for a report to be delivered on Sunday evening. You can now respond immediately and proactively to the key problems presented to the company.

You can easily see this UI metaphor applying to any Line of Business: Sales, Marketing, Service, Support.

This is where I see the next generation of software headed. SaaS-based Performance Management solutions using new UIs that enable Line of Business owners to better perform their jobs. Cerebellum integration will still apply today but in the not so distant future “Predictive Performance Management” may obviate much of that as well! But, that will be the subject of a different post.

  • http://hiteshee.wordpress.com Hitesh Parashar

    Bruce:

    Interesting that you mentioned “Predictive Performance Management”. Are you following any start-ups in this area?

    – Hitesh.

  • http://www.nastel.com Application Performance Management

    WOW, what a detailed article.

    How do you see Predictive Performance Management being utilized in the 2010?

  • http://www.interwest.com Bruce Cleveland

    Instead of answering your questions here, I committed to posting something further on this topic in a future blog. I will do so as my next blog entry in a couple weeks.

  • Pingback: Software as a Service (SaaS) - The Case for RPM