Cross-posted on RecruitingBloggers.com
In Part I of this series I mentioned that process played a big role in why so many ATS implementations go badly and since Amitai Givertz raised all the right questions in a comment on that post so let's dig in. Amitai writes,
The first point, that companies often have their own particular processes for doing a given activity, is beyond argument. The second point, that these processes produce unique value, is increasingly controversial, and deserves to be viewed with as much skepticism as respect. Companies are like tribes and while tribal customs often started for a good reason, they often survive long past their time by virtue of inertia.
In my professional experience, I've found that the harder a company defends their unique way of doing things, the less they usually have in the way of detailed process metrics on how things actually get done. A great example of this was the recent WSJ article on how Google is slimming down their notoriously drawn-out and capricious hiring process by analyzing which interview questions and screening criteria actually served as good indicators of success. A year ago Google's recruiters and managers would have turned their noses up at anyone who suggested their way of doing things was anything less than brilliant and 100% necessary. In fact, had any ordinary company adopted Google's tactics, they would have led to near-certain disaster.
As for the last two points, the best reference point for these comes from theCRM world, which has far more brains and money behind it, and which solves a similar set of problems. If anything, sales is a good deal more variable, since selling cars is different from selling jet engines or enterprise software packages, so you would expect extensive customization to be the rule of the day. And yet, the largest trend in the past five years has been the move towards smaller, simpler, and more off-the-shelf implementations in all but the very largest companies. The reason at its most simple is that by 2002, CRM had become a byword for “behind schedule, over budget, and no end in sight†among chief executives.
The idea that a system can be tailored to fit your processes to a T is quite lovely. As are the ideas of the Easter Bunny and the Tooth Fairy, both of which are only slightly more unrealistic. The reason is that customization and even “configuration†as vendors love to call it quickly become exercises in custom software development. Given how bad so much software is, I’m not surprised how many users think they could do it better themselves. Then again, given how bad so much software is, this isn’t setting a very high standard. The hardest part is not picking platforms or writing code or even drawing pretty icons to put on the pages—it is getting the process and screen flow of the application right, and there is no way to do this but vast amounts of time and expertise.
So, are you feeling lucky?
In my experience you are lucky if you get it right the second time; getting it right the first is almost out of the question. Vendors have in the past obliged this all too willingly, as the endless stream of professional services revenue is almost too good to resist. Switching costs are sufficiently high that a system needs to become truly intolerable before it gets booted, and in practice the last time this happened on a large scale was when web-based systems started replacing client-server tools like Restrac and Resumix in the mid-late 90s. Ironically this approach doesn't work well even for vendors, but that's a story for another time.
In Part I of this series I mentioned that process played a big role in why so many ATS implementations go badly and since Amitai Givertz raised all the right questions in a comment on that post so let's dig in. Amitai writes,
Without a process map that fully documents the internal workings that will be automated how can any solution be "made to fit?" I think the problem with ATS and other recruitment technologies in general is that they are made to automate a process per se and not the organization's process exactly, each organization being somewhat unique culturally, environmentally, operationally and so on.At risk of putting words in Amitai's mouth, I am going to draw the following conclusions from his comment for the sake of discussion:
- Companies have unique processes
- These unique processes create unique value
- Process automation is a good way to increase productivity
- Therefore, it is worth customizing software to automate your unique processes
The first point, that companies often have their own particular processes for doing a given activity, is beyond argument. The second point, that these processes produce unique value, is increasingly controversial, and deserves to be viewed with as much skepticism as respect. Companies are like tribes and while tribal customs often started for a good reason, they often survive long past their time by virtue of inertia.
In my professional experience, I've found that the harder a company defends their unique way of doing things, the less they usually have in the way of detailed process metrics on how things actually get done. A great example of this was the recent WSJ article on how Google is slimming down their notoriously drawn-out and capricious hiring process by analyzing which interview questions and screening criteria actually served as good indicators of success. A year ago Google's recruiters and managers would have turned their noses up at anyone who suggested their way of doing things was anything less than brilliant and 100% necessary. In fact, had any ordinary company adopted Google's tactics, they would have led to near-certain disaster.
As for the last two points, the best reference point for these comes from theCRM world, which has far more brains and money behind it, and which solves a similar set of problems. If anything, sales is a good deal more variable, since selling cars is different from selling jet engines or enterprise software packages, so you would expect extensive customization to be the rule of the day. And yet, the largest trend in the past five years has been the move towards smaller, simpler, and more off-the-shelf implementations in all but the very largest companies. The reason at its most simple is that by 2002, CRM had become a byword for “behind schedule, over budget, and no end in sight†among chief executives.
The idea that a system can be tailored to fit your processes to a T is quite lovely. As are the ideas of the Easter Bunny and the Tooth Fairy, both of which are only slightly more unrealistic. The reason is that customization and even “configuration†as vendors love to call it quickly become exercises in custom software development. Given how bad so much software is, I’m not surprised how many users think they could do it better themselves. Then again, given how bad so much software is, this isn’t setting a very high standard. The hardest part is not picking platforms or writing code or even drawing pretty icons to put on the pages—it is getting the process and screen flow of the application right, and there is no way to do this but vast amounts of time and expertise.
So, are you feeling lucky?
In my experience you are lucky if you get it right the second time; getting it right the first is almost out of the question. Vendors have in the past obliged this all too willingly, as the endless stream of professional services revenue is almost too good to resist. Switching costs are sufficiently high that a system needs to become truly intolerable before it gets booted, and in practice the last time this happened on a large scale was when web-based systems started replacing client-server tools like Restrac and Resumix in the mid-late 90s. Ironically this approach doesn't work well even for vendors, but that's a story for another time.