In Latin America there are many companies that do not handle clock systems, but that also have a very complex time scheme with concepts such as (prize
perfect attendance etc), there is also the case of clock systems that only have a record of start time, end time and breaks, and all the concepts of overtime, night bonuses, overtime with percentages depending on the amount accumulated in weeks, etc are driving by time schema. I can assure you that 80% of the companies that I have had the opportunity to work on their SAP implementations in this area of the planet are handled like this. How can they handle that in Success factors
I have to disagree with Sven’s reply back to Vinodh re customisation of time and payroll.
We have customers who, due to their Enterprise Agreements (EAs, Australian awards) have been forced into, or dreamed up, some weird and wonderful conditions. This entails either heavy config in Time Eval, and sometimes even customisation.
For years with these customers I’ve advocated doing to easier EAs with easier conditions, but for various reasons they haven’t or couldn’t. As a result they introduce new EAs, with more complexity. This further complicates the system, i.e. Time Eval, as we have to build for the current EA as well as the previous ones, to cater for retro. We’ve even sat with their Industrial Relations people, during the negotiation process, to ‚help‘ them with the wordings and proposals with the aim of reducing complexity.
Arguably a WFM such as Kronos can deal with this, so that is probably the future in this brave new world. But then integration becomes the bane of our/their lives, with interfacing from WFM to EC to SAP backend and back. That is what I see as our immediate pain point as we move into the cloud.
Sven Ringling
Hi Paul,
I don’t think we are in disagreement here. If course there are many customers, who’ll need more complex options than EC timesheet offers and I understand Australia is a hotbed for this. But there are also many customers, who can move to EC time and will be happier.
And then between these two groups there are customers, where simplification and move to EC would make a lot of business sense, but a lack of willingness to change or political reasons make it practically impossible.
Thank you Sven for the concise write up and all the great questions!
I’ve got a question, too. In ECC 6 CATS is feeding other SAP applications such as Payroll, PM, and Controlling. Using time management in EC manages staff entitlements and integrates with payroll nicely. How is it dealing with the other requirements where work orders and project information need to be updated? Is the integration via CATS (which I would assume considering your point in the article) or directly to the relevant SAP apps (which might be an option considering customers may also have non SAP integration needs)?
thanks
Frank
Sven Ringling
Hi Frank,
so far, SAP still sticks to the statement that EC timesheet is not meant to replace CATS in any shape or form – it allows for one simple field for a cost object. At the moment, imo, it’s either or, although you could probably move timesheet times into CATS. How CATS does / will looks like in S/4, I don’t know.
It’s probably safe to assume that the eco-system will produce various options to move EC time data to S/4 in future in some shape or form.
We need to keep in mind that EC time is meant to be and stay lean and simple. So, I trust that it won’t develop into an ABAP-hours eating monster like CATS to feed our consulting profession ;-)
Frank Gebhardt
Hi Sven,
thank you for your answer. I feared/expected that and agree – no ABAP monster ;)
A possible solution scenario would be to untangle CATS from Payroll, use EC Time for its core purpose (as automatic as possible) and CATS on an exception basis (only for time that need recording against work order etc.). That would avoid/limit double data entry.
so if on-prem goes away. how do other apps that rely on mini-master (like cats etc.) get this data?
Sven Ringling
Hi Howard,
an HR mini master as required for CATS or any other processes, where you need to assign an employee will be part of S/4 HANA. It can (and should) be fed from SuccessFactors as part of the standard integration scenario.
Are you saying there is not a road map for on premise with an EC front end. That seems odd given that there are customers deploying that now.
Sven Ringling
Hi David,
I’m not sure what you mean with „on-premise with an EC front end“. If you are referring to a scenario where payroll runs on premise and everything else is in EC, this is currently covered by the core hybrid integration scenario and the long term roadmap is going to EC Cloud Payroll. It can still make sense to implement on premise payroll now: the transition is relatively easy because for almost all practical purposes EC cloud payroll IS the existing on premise payroll. New implementations just should not go for a lot of custom development as it’s unlikely you can carry that over.
If you really mean EC as a pure frontend – like a replacement of ESS/MSS for on premise: I am aware that some customers let themselves be lead into that screnario by big system integrators / „consultancies“, who are in dire need to get their huge bench of people with obsolete programming skills busy.
Whilst you can always imagine a scenario where something like that could make sense as an interim solution, because you need the new „front end“, but really can’t make teh full move fast enough, assuming it as a long term scenario is, with all due respect, ludicrous.
To begin with: yes, it does fly into teh face of the current SAP roadmap and even though some customers bank on extensions, I wouldn’t bet on any significant roadmap changes. (The calculation of the big SI is different: is they have e few of these customers they can offer them to host and maintain their obsolete solutions at excellent margins, once SAP pulled the plug).
It also doesn’t make any sense from an architecture point of view: these are two completely different systems. It’s not even like trying to fit a Boing engine into an Airbus plane. It’s like building a Tornado jet around a Spitfire engine (or a Mustang for our American friends). EC has a very different philosophy and there aren’t teh easy 1:1 matches you’d need.
Finally, from an IT strategy point of view, it deserves nothing, but a life time sentence. With your cloud subscription you pay for the infrastructure as well as for the software. You should be freed of all infrastructure chains – no longe rneed that space, hardware, software and, most notably, know-how. This moves gives you the worst of both worlds. Also, the speend of innovation the cloud concept should bring you is out of the window, because not only does your „backend“ hold it back, but the a complext interface you need slows you down even more.
Just scratching on the surface, but I hope it gives you an idea. Only go for this, if it’s an interim scenario and it’s the only alternative (waiting to be ready for a proper move is also an alternative) for very very good reasons.
Anyway, thanks for asking this question, a sit hopefully helps some other reader to spot their system integrator’s plan to install a money printing machine for themselves.
Hi Sven,
you wrote THE definitive summary – nice.
Personally, I would expect to see the 2025 date extended again. There are companies having strong reasons against moving to the cloud; plus given that the EC Payroll is – to all effects – the HCM hosted solution, it will be maintained… so why not extend its official life? it is being ported to S/4 (but not in a simplified version).
As a reply to Vinodh, EC payroll is a hosted HCM Payroll solution. So much of the schema and requirements should be possible, although I expect some limitations based on the hosting model.
Not so when it comes to Time Management – and as Sven correctly states, EC contains a simplified Time-off and Time Sheet approach (that keep being extended), or requires a complementary, integrated approach.
Sven Ringling
Thanks a lot, Chiara!
it’s certainly a matter of speculation, but if there are enough customers, I believe there will be a deal in some shape or form. For most customers, there should be better reasons to switch than the deadline
Hi Sven, good opinions and clarity, thank you. Totally agree SuccessFactors is completely affordable as an HR system for the SME space.
From speaking to our current SAP HCM clients, I can’t see the ROI for SAP HCM Payroll users to move to the Employee Central payroll given the underlying engine is the same unless their current SAP Payroll is over customized and they want to re-implement. EC Payroll is great for those completely new to SuccessFactors and is still the „envy“ (as you rightly put it) to other cloud providers as it is so mature.
Best Regards, Steve
Sven Ringling
Hi Steve,
I could see one easy biz case for cloud payroll: if payroll the last piece you have in SAP on-prem, TCO for infrastructure and operations are enormous.
Paul W
There is an argument for moving existing customers to EC-Payroll. By going to EC the customer can move away from Fiori and the portal. They get a nice new ESS/MSS, and mobility thrown in for free. If you have customers on an old portal, and/or don’t have mobility yet, it gives them a lot for a minimal cost.
It also gives them a far better user experience than the old grey/blue R3 screen.
Sven Ringling
I agree in principle Paul, but:
– no way you get away from Fiori. SF is just in the process of Fiori-isation. Seen the new ee profile recently?
– EC payroll still does have a lot of old blue/grey moments for core users
I’m not saying EC will cover everything you can do in old PT. Customers have the two choices for a reason:
– EC timesheet for the less complex cases, where the new solution will be much simpler to maintain and more uset friendly
– the partners solutions that cover complex cases better than on-premise PT
I am convinced that many customers will be able to use EC timesheet, if they don’t try to replicate the old stuff 1:1, but re-think, what they really want to achieve.
Nice post. Thanks for keeping us updated on the development’s.
Do you really think that all the customization’s that we do in Time schema’s & Payroll’s schema as per client requirements can be accommodated in Success factors ?
Sven Ringling
Hi Vinodh,
definitely not.
I believe that 75% of these customisations are currently unnecessary:
– half of it is done. because consultants at work don’t understand the system and process and therefore can’t leverage the standard as well as they should
– half of the remaining 50% could be avoided, if customers would go after business value and let themselves be guided towards lean processes, rather than emulating what they had in th epast plus every other new non-value-adding idea of individuals.
When really scrutinizing potential for simplification, a lot (if not most) of customers can migrate to EC time at some point in the future.
The remaining customers will need to go with a partner solution as mentioned.
In Latin America there are many companies that do not handle clock systems, but that also have a very complex time scheme with concepts such as (prize
perfect attendance etc), there is also the case of clock systems that only have a record of start time, end time and breaks, and all the concepts of overtime, night bonuses, overtime with percentages depending on the amount accumulated in weeks, etc are driving by time schema. I can assure you that 80% of the companies that I have had the opportunity to work on their SAP implementations in this area of the planet are handled like this. How can they handle that in Success factors
nice blog
wow what an article ,thanks for providing blog to post
nice article
Great information, thank you for writing this. I love the mechanical horse analogy.
Very good information and very easy to understand.
Hai, thanks for sharing nice information. here you can go for demo.
I have to disagree with Sven’s reply back to Vinodh re customisation of time and payroll.
We have customers who, due to their Enterprise Agreements (EAs, Australian awards) have been forced into, or dreamed up, some weird and wonderful conditions. This entails either heavy config in Time Eval, and sometimes even customisation.
For years with these customers I’ve advocated doing to easier EAs with easier conditions, but for various reasons they haven’t or couldn’t. As a result they introduce new EAs, with more complexity. This further complicates the system, i.e. Time Eval, as we have to build for the current EA as well as the previous ones, to cater for retro. We’ve even sat with their Industrial Relations people, during the negotiation process, to ‚help‘ them with the wordings and proposals with the aim of reducing complexity.
Arguably a WFM such as Kronos can deal with this, so that is probably the future in this brave new world. But then integration becomes the bane of our/their lives, with interfacing from WFM to EC to SAP backend and back. That is what I see as our immediate pain point as we move into the cloud.
Hi Paul,
I don’t think we are in disagreement here. If course there are many customers, who’ll need more complex options than EC timesheet offers and I understand Australia is a hotbed for this. But there are also many customers, who can move to EC time and will be happier.
And then between these two groups there are customers, where simplification and move to EC would make a lot of business sense, but a lack of willingness to change or political reasons make it practically impossible.
Thank you Sven for the concise write up and all the great questions!
I’ve got a question, too. In ECC 6 CATS is feeding other SAP applications such as Payroll, PM, and Controlling. Using time management in EC manages staff entitlements and integrates with payroll nicely. How is it dealing with the other requirements where work orders and project information need to be updated? Is the integration via CATS (which I would assume considering your point in the article) or directly to the relevant SAP apps (which might be an option considering customers may also have non SAP integration needs)?
thanks
Frank
Hi Frank,
so far, SAP still sticks to the statement that EC timesheet is not meant to replace CATS in any shape or form – it allows for one simple field for a cost object. At the moment, imo, it’s either or, although you could probably move timesheet times into CATS. How CATS does / will looks like in S/4, I don’t know.
It’s probably safe to assume that the eco-system will produce various options to move EC time data to S/4 in future in some shape or form.
We need to keep in mind that EC time is meant to be and stay lean and simple. So, I trust that it won’t develop into an ABAP-hours eating monster like CATS to feed our consulting profession ;-)
Hi Sven,
thank you for your answer. I feared/expected that and agree – no ABAP monster ;)
A possible solution scenario would be to untangle CATS from Payroll, use EC Time for its core purpose (as automatic as possible) and CATS on an exception basis (only for time that need recording against work order etc.). That would avoid/limit double data entry.
so if on-prem goes away. how do other apps that rely on mini-master (like cats etc.) get this data?
Hi Howard,
an HR mini master as required for CATS or any other processes, where you need to assign an employee will be part of S/4 HANA. It can (and should) be fed from SuccessFactors as part of the standard integration scenario.
Are you saying there is not a road map for on premise with an EC front end. That seems odd given that there are customers deploying that now.
Hi David,
I’m not sure what you mean with „on-premise with an EC front end“. If you are referring to a scenario where payroll runs on premise and everything else is in EC, this is currently covered by the core hybrid integration scenario and the long term roadmap is going to EC Cloud Payroll. It can still make sense to implement on premise payroll now: the transition is relatively easy because for almost all practical purposes EC cloud payroll IS the existing on premise payroll. New implementations just should not go for a lot of custom development as it’s unlikely you can carry that over.
If you really mean EC as a pure frontend – like a replacement of ESS/MSS for on premise: I am aware that some customers let themselves be lead into that screnario by big system integrators / „consultancies“, who are in dire need to get their huge bench of people with obsolete programming skills busy.
Whilst you can always imagine a scenario where something like that could make sense as an interim solution, because you need the new „front end“, but really can’t make teh full move fast enough, assuming it as a long term scenario is, with all due respect, ludicrous.
To begin with: yes, it does fly into teh face of the current SAP roadmap and even though some customers bank on extensions, I wouldn’t bet on any significant roadmap changes. (The calculation of the big SI is different: is they have e few of these customers they can offer them to host and maintain their obsolete solutions at excellent margins, once SAP pulled the plug).
It also doesn’t make any sense from an architecture point of view: these are two completely different systems. It’s not even like trying to fit a Boing engine into an Airbus plane. It’s like building a Tornado jet around a Spitfire engine (or a Mustang for our American friends). EC has a very different philosophy and there aren’t teh easy 1:1 matches you’d need.
Finally, from an IT strategy point of view, it deserves nothing, but a life time sentence. With your cloud subscription you pay for the infrastructure as well as for the software. You should be freed of all infrastructure chains – no longe rneed that space, hardware, software and, most notably, know-how. This moves gives you the worst of both worlds. Also, the speend of innovation the cloud concept should bring you is out of the window, because not only does your „backend“ hold it back, but the a complext interface you need slows you down even more.
Just scratching on the surface, but I hope it gives you an idea. Only go for this, if it’s an interim scenario and it’s the only alternative (waiting to be ready for a proper move is also an alternative) for very very good reasons.
Anyway, thanks for asking this question, a sit hopefully helps some other reader to spot their system integrator’s plan to install a money printing machine for themselves.
Hi Sven,
you wrote THE definitive summary – nice.
Personally, I would expect to see the 2025 date extended again. There are companies having strong reasons against moving to the cloud; plus given that the EC Payroll is – to all effects – the HCM hosted solution, it will be maintained… so why not extend its official life? it is being ported to S/4 (but not in a simplified version).
As a reply to Vinodh, EC payroll is a hosted HCM Payroll solution. So much of the schema and requirements should be possible, although I expect some limitations based on the hosting model.
Not so when it comes to Time Management – and as Sven correctly states, EC contains a simplified Time-off and Time Sheet approach (that keep being extended), or requires a complementary, integrated approach.
Thanks a lot, Chiara!
it’s certainly a matter of speculation, but if there are enough customers, I believe there will be a deal in some shape or form. For most customers, there should be better reasons to switch than the deadline
Hi Sven, good opinions and clarity, thank you. Totally agree SuccessFactors is completely affordable as an HR system for the SME space.
From speaking to our current SAP HCM clients, I can’t see the ROI for SAP HCM Payroll users to move to the Employee Central payroll given the underlying engine is the same unless their current SAP Payroll is over customized and they want to re-implement. EC Payroll is great for those completely new to SuccessFactors and is still the „envy“ (as you rightly put it) to other cloud providers as it is so mature.
Best Regards, Steve
Hi Steve,
I could see one easy biz case for cloud payroll: if payroll the last piece you have in SAP on-prem, TCO for infrastructure and operations are enormous.
There is an argument for moving existing customers to EC-Payroll. By going to EC the customer can move away from Fiori and the portal. They get a nice new ESS/MSS, and mobility thrown in for free. If you have customers on an old portal, and/or don’t have mobility yet, it gives them a lot for a minimal cost.
It also gives them a far better user experience than the old grey/blue R3 screen.
I agree in principle Paul, but:
– no way you get away from Fiori. SF is just in the process of Fiori-isation. Seen the new ee profile recently?
– EC payroll still does have a lot of old blue/grey moments for core users
Thanks, Vinod.
I’m not saying EC will cover everything you can do in old PT. Customers have the two choices for a reason:
– EC timesheet for the less complex cases, where the new solution will be much simpler to maintain and more uset friendly
– the partners solutions that cover complex cases better than on-premise PT
I am convinced that many customers will be able to use EC timesheet, if they don’t try to replicate the old stuff 1:1, but re-think, what they really want to achieve.
Nice post. Thanks for keeping us updated on the development’s.
Do you really think that all the customization’s that we do in Time schema’s & Payroll’s schema as per client requirements can be accommodated in Success factors ?
Hi Vinodh,
definitely not.
I believe that 75% of these customisations are currently unnecessary:
– half of it is done. because consultants at work don’t understand the system and process and therefore can’t leverage the standard as well as they should
– half of the remaining 50% could be avoided, if customers would go after business value and let themselves be guided towards lean processes, rather than emulating what they had in th epast plus every other new non-value-adding idea of individuals.
When really scrutinizing potential for simplification, a lot (if not most) of customers can migrate to EC time at some point in the future.
The remaining customers will need to go with a partner solution as mentioned.