Implementing SuccessFactors Employee Central with a SAP background
My background is technical and focused on SAP, so invariably cloud implementations were going to bring new challenges. Looking for knowledge on what to expect in terms of project management I found there are a few blogs (the new manual), some notes on Employee Central project implementations, each giving details and recommendations on how to be successful. No criticism on any of these, but I haven’t found the direct Employee Central specific items that I experienced on an implementation. The article listed the project methodology adjustments and impacts without detailing the causes. I won’t address any of the project methodology principles but wanted to highlight a few very specific impacts an Employee Central implementation will have any project.
Since some of these items increase your project risks it will be prudent to ensure that you offset these risks against the business decisions and benefits that you aim to achieve from implementing Employee Central. The project impacts and risks are temporary (months) while the implementation and planned benefits should have a much longer lifespan (years).
Cloud landscapes versus traditional SAP landscapes
One of the first and seemingly simple differences are that SAP has a strict three tiered landscape. Something etched into every trained SAP Basis consultants mind! The three tiered landscape is supported by a robust transport layer that was built to enable a mechanism to move configuration between systems (development, quality and production). With Employee Central you don’t have a tiered landscape. You may choose to have more than one Employee Central instance and use each of the instance for a specific purpose (development or production), but the instances will not be linked within the landscape. There is no transport layer and system to move the configuration and provide version control. The configuration is moved (some XML imports can be done) and recreated on each instance.
Without this help on the system level, the configuration and version control need to move up to the project management methodology. The project team will need to track it and ensure that they care of it.
Release schedules
SAP is known for upgrades and support packs. Both for the complexity and regular maintenance caused. Unfortunately, some of the bad rapport is incorrect assigned because some of the changes come from the fact the legal requirements dictate these changes. Also, because of the power of SAP’s limitless customization the balance between simplicity and future maintenance is not always the easy path to follow.
Employee Central promise to take care of all of this pain since the solution and releases are in the cloud the releases schedules are applied and takes care of changes. The tradeoff for this benefit is the lack of control of applying new releases and the visibility of what is contained in each release. You won’t have the detailed notes, version control to do comparisons or even SPAU (you may even miss the SPAU).
EC debugging and error handling vs SAP development workbench
Good or bad, every SAP consultants used the workbench to search data dictionary or the trace through some ABAP code. Find the exact failure point or even using the code as a roadmap for understand was and still is key.
Employee Central is a closed system. There is no application development interface, and the only access is via configuration layer. If the only benefit was simplicity, and reduced maintenance it would be ideal, but a great deal of self determination and control is given up in return. Taking into consideration that error handling is still in the initial stages of maturity (I am sure it will improve with future releases) the project will have to deal with very vague errors and no solution to debug or resolve the issues. The solution in place the Employee Central support channel and I comment more on this later.
Employee Central data migrations and data handling
SAP started with the batch import system and later LSMW became the staple food of many data imports. Both provided options and included enough control with error handling and feedback.
With EC the foundation object configuration generates import templates (spreadsheets) that need to populated and re-imported. The design is focused on simplicity and low maintenance. The error handling during the import process does however need to improve. Experiences included successful error reporting, but without any data in Employee Central. Also because the relationships between Employee Central objects (any HR objects on SAP as well) is so fundamental if any of these are not correctly configured the import will fail but without a clear indication of why or where to look to resolve the issue.
A last point to note is that the SAP landscape firstly lacked an ability to copy data between systems. For example from production to quality for testing purposes. This was initially solved by the Data Sync Manager and later developed into a huge market with many solutions. Employee Central has reset the clock and the last few years, and there is again no solution to move that one employee from production to quality to test. Because Employee Central is a closed solution (no third party software development solutions) I am not sure what the future holds in terms of solving this issue.
Employee Central support layer and channels
Logging a SAP support request was simple and provided direct feedback on the progress. Granted not all requests were resolved on the first attempt, but the support interface was simple and partly transparent. The body of knowledge that was generated at the back of all the support was staggering. Searching through the notes and finding a similar problem and associated solution was very powerful.
Employee Central will have build body of knowledge over time, but currently the main concern is that access the JIRA support is not available in the same sense that SAP was. It is effective an internal only support solution that cannot be accessed for logging or even search only access. Hopefully the access improves or alternatively that a secondary body of knowledge is made available to assist clients and partners.
I hope some of the expected impacts are clearer. If you are involved in a current Employee Central implementation, I wish you success. If you are planning an EC implementation make the adjustment and planning to ensure that cover and manage the few items I highlighted. Lastly, make sure have an implementation partner that is able and willing walk this road with you.
Hi Nico,
I think this was a much awaited blog from someone who has been involved in the project management space of an EC implementation. What you share will be very beneficial to customers and consultants who see an EC implementation in the horizon.
With regard to the transport mechanism, agree that as SAP consultants we take transactions like SCC1 for granted. This is not the case with Employee Central where almost any configuration done in the OneAdmin UI needs to be duplicated in Production, for e.g. MDF configuration.
However, Employee Central allows copying some items in Company Settings, such as Route maps, Competencies, Rating scales etc, and Role Based Permissions but from experience it is still in the "bugs and fixes" stage and often times as consultants re-creating the configuration(done in Admin UI) is the smarter way.
Thanks for taking the time to share your experience.
Warm Regards,
Jyoti
Thank you for the comments Jyoti.
I do recognize that I generalized on some aspects, like you point in your example. I don't have a full roadmap of Employee Central's future but I would venture a guess that some kind of transport layer/mechanism would be part of the solution. Like the tag line to a movie would say "from the creators of SAP, comes... the new Employee Central".
Hi Nico,
I would have to disagree with this statement:
There is an API that can be used to access the data within the system (the SFAPI (which is being enhanced to a more RESTful(ish) version)) and SAP themselves are running an example of an application developed on top of and integrated with EC Data Eat like never before: SAP Networking Lunch
However, I do feel your pain with respect to no longer being able to debug through the guts of the system. I guess that is the trade-off when you blackbox away implementation methods for a SaaS solution.
Thanks for sharing your experiences.
Cheers,
Chris
Hi Chris,
We agree that the external API exists, and I can comment that it worked for the external integration (EC API --> SAP PI --> third party). It is well documented and worked as expected.
What is missing is the access to the internal development environment, resulting in a "blackbox".
Thank you for reading and commenting.
Regards,
Nico
Hi Chris,
Your comment kept me thinking about the reason for the response. And I mean that in the positive sense. What I came up with is some ideas regarding the main purpose/benefits and use of the SAP ABAP development environment "open system" compared to a "blackbox"
1. Your example, just plain debugging and for understanding. SF EC is closed and the error code is all you get. It was the lowest use of the SAP ABAP access but was and is still useful. It is however never on any sales pitch, "Use SAP because you can dig around in the guts".
2. Extending the solution, and here SF Employee Central MDF (Meta data framework) is doing a great job without exposing the development in the traditional sense. So comparing apples to apples EC would be simpler and quicker with less chance of coding errors. Luke Marson's blog on MDF is very useful and I would note that the comments regarding simplicity and avoiding building "loops" is good advice.
3. Integrating to the solution. Both SAP and EC compare well. Maybe SAP because of the long development history is a little more confusing since it has a few different options for interfacing.
4. Building new solution within the product IDE. Partners and clients could build anything and I was involved in may projects that today would be impossible on EC.
Kind regards,
Nico
Hi Nico,
Great blog and it's really interesting to read from your first-hand experience of managing an Employee Central project. Your insights are valuable and I already know that this blog has come to the attention of folks like Thomas Otter and Naomi Bloom.
Chris Paine is partially right as are you about the "closed" system. SAP are planning providing functionality in the SAP HANA Cloud Platform for extending SuccessFactors Employee Central with custom applications, but the system itself is a "black box". I think that while it is possible to build some custom application to handle some of the obstacles you and your customers have faced, I believe that it is better to introduce standard functionality to cover most of them. I see SAP HANA Cloud Platform as a way of providing customer-specific enhancements rather than fixing gaps in core functionality.
Best regards,
Luke
HI Nico,
Liked your blog. Even though some of the points are familiar, yet it was good to get a view from first hand implementation experience. Good job.
Thank you Vinay
Good discussions generated by the blog. Just a few comments to add to the discussion-
1. MDF is being extended and works like a charm so we will see more extensibility with Employee Central.
2. Employee Central is enabling customers with the "discipline of standardization", there are many who are using this as an opportunity to reassess and redesign their processes.
3. I have been working with EC prospects and customers for almost a year now and the common theme in all discussions irrespective of the size of the customer, is actually the simplicity and minimal dependence on SIs to maintain the system, this causes a huge reduction on annual support contracts for the customer amongst other things.
4. I also think that providing capabilities with SAP HANA Cloud platform to build customer specific enhancements is the prudent and wise approach to enhancing the product design as necessitated by the customer instead of building the enhancements as a core standard offering, as robust as SAP is and don't get me wrong but we have all been on implementations where the customer may not need the whole 9 yards of the core solution but they inevitably have to pay for that development in the form of license cost and spend on technical upgrade implementations.
With a SaaS solution like Employee Central, you have an option and can choose to invest resources or not.
Lastly, it is critical for Partners to understand and communicate the inherent design principle of Employee Central and educate customers. This is the difference I am seeing being on the ground and what is differentiating a happy customer from a not so happy one.
Thank you Jyoti.
I am looking forward to the SAP HANA Cloud development and how it will extend the solution and options.
Hi Jyoti,
"discipline of standardization”? There is a ring of truth there. The same truth that has SAP implementations eliminating mods to the core code. Yet I also feel it is mainly a sales pitch that is so deeply engrained in SaaS vendor's solutions that we have forgotten that it was built as an item to put in the pros/cons table when comparing against a solution that could be enhanced.
I also think that whilst SAP HANA Cloud Platform extensions to SAP SaaS offerings are licensed separately from the LoB products like EC, to think of them as outside the "core" is to misunderstand the "inherent design principle" of a SaaS solution which can be safely and supportably enhanced by customers to meet their needs above and beyond the "best of suite" business solutions.
Cheers,
Chris
Hi Nico,
Nice Blog. Relevant points. I think for a SaaS platform, extensibility is always a challenge. This would be true for other offerings and other vendors. Though it's good to see great improvements in EC.
-AK
hi Nico,
Thank you for your blog ! I am started to search about Success Factors since September 2014. After reading tons of overview blogs about what Success Factors offer to customers, such blogs like yours help us o get view of first hand implementation. It will be better to share such experiences more often.
Regards,
Fuad