The Collocator

a little HCM data visualization

Mario Herger posted on the topic of data visualization the other day and emphasized how important it is to bring out the salient aspects of a data set and to not go overboard with the visualization methods available nowadays.

While I'm wary also of how meaningful data can be obscured by fancy visualization methods, I couldn't help letting my imagination go about an interactive data 'sketch' Ben Fry recently put up on his site. This data representation is fun to use and it looks great. It just confirms how mode of presentation remains an important part of inviting a user to look at data and to help the user make sense of it. Take a look.                                                         

The breakdown of Ben's particular visualization for baseball team rankings may be summed up as follows: constants on the right are tied to an element on the left where the elements on the left are sorted according to some criterium. In Ben's example the figures on the right show the payroll of baseball teams and the listing on the left shows the ranking of each team on a given date. If a team's ranking sits higher or on the same level as its relative payroll then the team's logo is tied to its payroll with a blue line; otherwise the line is red.

So here we have relative positioning and color (as well as the thickness of the connector) helping us make a judgement about whether or not a team's payroll is justified.

What makes the visualization even more compelling is the interactive aspect of it. By moving through the timeline one can very easily see how the rankings are changing relative to payroll as the season carries on.

Here are a few simple examples of how this model might be applied to present HCM related data (including a timeline at the top):

Pursuing today's HCM project goals

A post by Don Dodge about Craiglist mentioned The Mythical Man Month by Fred Brooks and launched me into this post. The second-system effect is my favorite theme in this book and I often think about it on SAP HCM implementation projects.

The second-system effect in essence states that an engineer will be sorely tempted to add those features to her second system that she wasn't allowed to on her first system development project. Bells and whistles and all sorts of desirable features will want to be introduced. The first system was successful in no small part because its scope and budget were strenuously controlled, but the temptation for the engineer is now to make the second system even more successful by delving into that wishlist. Thereby missing an important fact about the success of the first.

SAP HCM implementations, especially when they include Benefits, Time Management and Payroll Management are technically demanding. They present plenty of opportunity for over-engineering technical solutions - e.g. for automating the handling of an exception that affects a small number of employees. The more experienced a systems integrator is with SAP HCM, the more tempting it becomes to automate just because she knows it's possible in SAP. Something to be wary of since this automation will take up time that could have been spent on something with better value-add.

That aside, it got me thinking about how we're scoping HCM projects today and how we might in future. As an example, today employee self-service is typically part of the initial roll-out. This wasn't always the case even after employee self-service technology became available. But now it is a leading practise and an integral part of improving HCM business processes.

Now, at least from what I see here in the US, is that most wall-to-wall SAP HCM implementations include OM, PA, BN Administration, Time and Payroll + ESS and maybe some MSS as an initial objective. If an organization is interested in SAP as a wholistic HCM solution then this picture might change in the not-so-distant future. We might instead be looking at e.g. OM, PA, ESS, BI, eRecruitment, Performance Management as the initial goal. (Plus MDM to keep SAP and remaining legacy databases in sync.) Benefits, Time and Payroll Management will come next - if these aren't outsourced.

One of the appealing things about such a development is that customers would get the strategic value-add of these functions relatively quickly, instead of having to wait until all the core transactional functions have also been implemented. From a project sponsorship perspective there's the advantage that this would allow the implementation of subsequent functions to occur under the protective umbrella of an early success.

Way down the road SAP customers might be looking at configuration-before-contract options - as Hasso Plattner divined in his Sapphire 2007 keynote.

the arts may help a little, hasso

Dan Fost wrote in The Tech Chronicles about SAP's Hasso Plattner's session at Software 2007 the other day. Plattner was asked about whether ERP software makers ought to look at e.g. Apple for ideas on the appearance of their software. Hasso had this to say:

Beautification is the wrong way. Google is the right way. I am a fan of this company. With all respect to the arts, the arts are not helping.

Be that as it may, I do hope at some point in the future SAP or a development partner or I myself if no one else wants to do it is going to develop a beautiful, artful, sexy way of scrolling through the employees in my cost center (among other things one could think of doing beautifully). I've made a clip of an MS SQL 2005 web ad I happened upon a while ago, and linked to it here. It's not as sharp as I'd prefer, and I should not consider becoming a hand-model - or a mouse-model, rather - but it makes the point. Here's a visual, almost tactile way of scrolling through customer or, employee, data. This is beautification to some extent, artful semi-minimalism, and I have a feeling SAP HCM customers would love it.

Derned if this is going to be done in a browser. But if it is built one day soon and on a browser-platform, I'll buy Hasso dinner. I'll make him dinner.

Cross-community value translation

If I were to ask a roomfull of experienced SAP consultants a particular question it’s near certain all hands will go up. The question has to do with the first response of a series we as consultants receive sooner or later upon submitting an inquiry on the powerful SAP online support system (OSS). This response is a good first response for  a system like the OSS. It’s the equivalent of checking that an electric device machine is plugged into an outlet before starting to troubleshoot the machine itself.

The first response would be to read the relevant documentation or to check a few basic settings. It’s typically proferred by what I like to refer to as the first line of defense, i.e. a less experienced OSS services agent.

Most of the consultants in that room would put up their hands that they’ve been on the receiving end of one of these basically unhelpful, but understandably necessary responses.

Most of those consultants will also tell you that unfortunately for the helpful folks servicing the OSS it can be a very frustrating reply. Frustrating because we would have already looked at the basic solutions and a number of other solutions besides. We know the manuals backwards and forwards. We feel like time is being wasted.

A consulting colleague recently confessed that he’d submitted his first OSS question after nearly 10 years in the business – a matter of pride he said. I daresay most of the rest of us seek help a little quicker, but even so we don’t OSS something until we’ve explored every avenue. We don’t want to be embarrassed on the OSS. Those messages will be there for anyone to see long after we’re gone.

I’ve thought for a while now that if only we had some sort of experience rating for OSS users then we could get past this problem. If you’re an experienced HCM time management consultant, say, then you won’t get the ‘read the documentation’ response for your questions. Instead, you’d immediately be patched through to an experienced OSS services consultant or a developer ready to tackle the question you’ve described in detail with examples and possible solutions. The trick is of course that we don’t have a universal OSS user rating system.

But we do have a rating system of sorts on the SDN.

So, wouldn’t it be grand if a person’s points on the SDN counted towards the level of OSS support experience they get on their first response? This would be a case of one community ‘rating’ finding currency in another, related community.  Call it cross-community value translation. It’s on the level of a person’s eBay seller reviews counting for something if that person started selling on Amazon. 

One can unravel this one quite a bit more. I’ll leave that for someone else or for later.

Duet, information death and email overload

This post had been written about a year ago, but I only started publishing to my blog a few days ago and it still seemed relevant. I wanted to get it off my chest. It’s about Duet and email. I altered it only a little here.

I expressed my skepticism about Duet using Outlook as a workflow communication channel. I was worried about how Duet might misuse an email mechanism for purposes that should best be handled with other mechanisms - such as applications for pulling up reports and workflow processing.

It’d be interesting to know what folks think of where Duet stands now, a year or so later.

So,: Bill French said 'email is where knowledge goes to die'. I largely concur with this.

But along come SAP and Microsoft with Duet, which threatens to dump workflow processes and even reports in my inbox. I am against that.

I am in the camp who thinks that Outlook is the wrong vehicle for bringing better usability to the broader user community. In fact, I believe the time has come for a new SAP HCM user interface and improved processes running on a thick-client, a smart-client with desktop and web components, mind you. Maybe more on that later.

The thing with workflow notifications is this: I want to be able to track, view and process workflow notifications in an application or applet that has been developed specifically for this purpose; something better than the OWA available on the SAP portal. If I could choose I'd want a graphical representation of the state of workflows that I'm involved with. I want reminders of urgent workflows in a place where I'd actually react to them, not where they're going to be mixed up with my email. I want to integrate workflow with email only when it's necessary. I don't want to be distracted by constant workflow messages, I want to be able to go TO it. Just put a workflow processing application somewhere in my main workspace and I'll take care of it.

Reports in Outlook are even worse. Just as I want to be able to go to Sharepoint or some wiki whenever I'm interested in some discussion about something (instead of being cc'ed on an email trail 50 threads deep), I want to be able to go TO the place where I can get my reports. I don't want to keep getting updates of a report every time it is re-executed or new information becomes available - it's not as if the email with a fresher version of the report automatically finds older versions and deletes them. Am I really going to want to remember that I should always look to see if there's a newer email with a fresher report than the one I'm looking at? I may be wrong, but it seems that this is what was going to happen.

Do I want my vacation time in SAP to be integrated in my Outlook calendar? Sure. But I also want my Outlook calendar at work to be synced up with my personal calendar on MSN or where ever; my personal items should of course be flagged automatically as private. Or vice versa.

I hope Thomas Otter won’t take exception to the fact that I’m referring to one of his recent posts (The future of HR systems and thinking?) twice in a row, but I think there’s really quite a lot to be explored in the following statement by him (a paraphrase of something Dennis Moore of SAP said):

HR systems today are all about capturing what the company wants to store about me. (grade, performance, salary and so on) HR systems in the future will capture what I want to tell the company about myself.

So to continue my rant: do I want to see my personal and address information in Outlook? Maybe. But what I definitely want to be able to do is to build a mashup where I can easily display and edit my addresses at all the different organizations and persons that have it - I want to be able to say, yes this is the address my employer has for me, now change my address at Social Security and at my bank to the same address.

Duet is a step in the direction of leveraging services to provide a better user interface and a more integrated 'data and process experience'. But I disagree that it's entirely a step in the right direction. We misuse email today, and among the things that will rescue us are better colloboration platforms. Platforms where we can easily publish information or subscribe to information. Platforms where we can easily build our own mashups of information we want to combine and coordinate with each other. Web 2.0 in the workplace.

I was not the only looking at Duet with a slightly skeptical eye - Zoli Erdos and Vinnie Mirchandani were also. Has to be said they were skeptical for different reasons than I; it's worth checking out their posts.

Vinnie quoted Charlie Wood (link seems to have rotten in the meantime) as saying

Ultimately I think Duet is a fantastic prototype of what's to come: solutions for exposing enterprise applications within familiar desktop tools. But where Duet is a proprietary, one-off integration, we will soon see generalized integration capabilities built on the lightweight, open standards of RSS and Microsoft's own RSS extensions, which add support for structured data and synchronization.

I’d like to see ‘generalized integeration capabilities’ for handling ‘structured data’ relevant to even the core elements of an HR and Payroll system, such as changing my address or bank account information.

harmony for service providers

For those of us unable to attend Sapphire 2007 it was a godsend that there was again a blogger’s corner this year. Thomas Otter posted a challenging question to us in the HR business (and I’ve taken the liberty to include myself as an SAP HCM service provider). His question was:

My questions to the HR folks reading this. What are you doing about social computing and networks? They are changing organizations as I write this. Will this pass the HR function by, or will you embrace it as a means to meaningfully connect with employees and their aspirations?  The time is now.

In the same post news is shared about Harmony, the up-and-coming social networking platform currently in use at Palo Alto. Assuming this platform is eventually going to make it into the hands of customers, I wanted to add a twist to the question Thomas asks, viz.:

How can we as service providers help customers use Harmony to connect with each other to share information about processes and practices ?

Customers do today have access to ASUG and various other forums to share information and help each other with questions. With Harmony it may be possible to take that one step further and share specific information about e.g. how inter-departmental employee transfers could be handled. Imagine a blog or wiki about this employee action and then the capability to social bookmark whichever ‘best’ process  percolates to the top.

wiki of my heart

i've been using wiki's for about 4 years now to collect all sorts of information snippets. my first wiki was fpwiki and today i use mediawiki. i've worked a bit with jot, i've experimented with sharepoint's wiki, tikiwiki, twiki, recently pbwiki and a bunch besides.

i'm a wiki fan. but the thing about wiki's is that they still have some way to go.

there are shortcomings  i find it difficult to live with. some wiki's like pbwiki and jot go some way towards dealing with them. e.g. when it comes to linking to an existing wikipage from another page - they're much better than sharepoint's wiki at doing this. yet, none of them go as far as they could.

the 1st thing i want is bi-directional integration with static publication applications and the 2nd is more options to introduce structure to one's wiki page landscape. maybe the 3rd thing - and there is a lot more besides - is innovative ways of dealing with versions, approvals and electronic signatures.