Recently, SuccessFactors Support had a meeting with one of my customers. They shared this great new tool called Configuration Center and encouraged my client to begin using this tool to transport changes through its environment. The client in turn was curious why we were not using Config Center and were instead using Instance Sync, which is today's standard process for moving Employee Central configuration. While I had done some cursory checkout of Configuration Center previously, I needed to investigate further to determine whether this should be adopted so that I could discuss with my customer.
Proceeding with my investigation, my first stop (always) is the implementation guide on help.sap.com. I immediately looked at the "Limitations" section.
https://help.sap.com/viewer/8c9fccb5d25142b1b8cba20640b5e923/2111/en-US/c7544baf07214e00846c47d8b654...
As you can see, there are only two limitations listed, and none for Employee Central. This made me think that Config Center must be at least on par with Instance Sync.
However, when I dug in, my review immediately surfaced a few limitations. Once I got to this list, I stopped further analysis so it's definitely possible there are more. I posted my findings on the partner portal and no one contradicted these so I'm assuming that they are accurate. As always, determining limitations is always risky because there is always the chance that I missed something. So with that caveat, here is my list after a minimal amount of investigation:
With these findings in hand, I posted a question from the partner portal hoping to get clarification. Was I correct that these are limitations? Can SF provide a list of limitations? I was told that rather than list out the limitations, I should look to the blog below for an itemization for what the tool can do. (I will stop here and ask why Blogs would be referenced as a primary source for anything? If there is information, why is it not in the implementation guide? I will leave that conversation for another day)
So based on SF's guidance, I consulted the blog:
https://blogs.sap.com/2021/04/20/configuration-center-new-way-to-view-download-and-transport-configu...
This blog purports to itemize the items that are available for migration. However, as I dug into this blog, I found it to be (hopefully unintentionally) misleading. Below are 3 examples:
Example 1 Workflows
Great! So I can migrate workflows, right? No. It just means that some of the ancillary configuration elements can be moved. Workflows cannot be moved via Config Center from what I can tell.
Example 2 Position Management Settings
I was pretty excited about this one! Moving the Position Management Settings configuration is something that Instance Sync cannot do today. However, when you look at the detail, it's actually only sending up the Employee Central Setting that enables Position Management. Again, misleading.
Example 3 Event Reasons
This seems to imply that the Configuration Center will transport the event reasons. But it doesn't. What does it send instead? The list of countries. Not exactly sure what countries have to do with event reasons, but I'll assume there is a rationale here.
So in summary, the official documentation lists no limitations and the blog I was told to consult is misleading. Since the documentation on this point is not clear, I will be: Configuration Center is not ready for most day-to-day use yet in Employee Central. If you want to get your feet wet? Great. But for most real-world changes, you need to continue to use Instance Sync for the time being. I have no doubt that in a year or two it will be better than Instance Sync but that day is not today.
The Impact Of Undocumented Limitations
It is disappointing when consultants and clients are left to figure out the state of solutions that have been released into the wild. I'll make a statement I've made on more than one occasion: It is more important to know what a solution does not do than it is to know what it does. Consultants and customers want to believe solutions do what they purport to do. We then invest time into using something only to find out (often late in the process) that the solution is not really ready for even typical use cases. More than once I have been one of the first to implement new functionality only to have to go to the customer late in the testing stage to tell them about an undocumented limitation would require either a workaround or abandonment of the new functionality.
Exacerbating the problem is that most of the time, if the vendor won't publicly identify the gaps users/consultants won't stick their neck out to call out shortcomings. Why? It's risky to provide criticism. First, even if I am right, I can be branded as a troublemaker. Second, It's very possible that my analysis, which was brief, could have misidentified a gap. The reality is that I don't have time to take a day and go line-by-line and figure out what a new tool can and cannot do. But my point is that I should not have to perform this analysis! SuccessFactors should be forthcoming with key limitations. I fundamentally disagree with the approach of "we are putting this out there, the solution will grow, and in the meantime, you can figure out the limitations yourself" employed here.
I just want to be clear that I do not think that this tool needs to be called out specifically. I have seen this practice employed by SAP/SuccessFactors previously. And I'm sure other vendors are guilty of the same. I am all for releasing products and allowing them to grow as long as there is full communication, which is not the case here.
If itemizing the limitations is not reasonable due to the limited nature of the solution, all SuccessFactors has to do is to put a caveat out to say "This is a limited toolset for now. We are putting this out there as a beta and would love to get your feedback". But this tool is no longer in beta and there are no limitations listed. And making matters worse, there is a full-featured incumbent tool, Instance Synchronization, that we are being asked to give up to start working with this new one.
The smart play for me would be just to keep my mouth shut and quietly tell fellow consultants and clients to stay away. I chose to speak up for two reasons.
Solutions don't need to be perfect when they are released. Customers don't expect this and often will deal with the gaps. What they don't want to deal with is surprises.
Proceeding with my investigation, my first stop (always) is the implementation guide on help.sap.com. I immediately looked at the "Limitations" section.
https://help.sap.com/viewer/8c9fccb5d25142b1b8cba20640b5e923/2111/en-US/c7544baf07214e00846c47d8b654...
As you can see, there are only two limitations listed, and none for Employee Central. This made me think that Config Center must be at least on par with Instance Sync.
However, when I dug in, my review immediately surfaced a few limitations. Once I got to this list, I stopped further analysis so it's definitely possible there are more. I posted my findings on the partner portal and no one contradicted these so I'm assuming that they are accurate. As always, determining limitations is always risky because there is always the chance that I missed something. So with that caveat, here is my list after a minimal amount of investigation:
- Configuration Center does not have an option I could find for moving business rules, which is probably the main element to be moved from one environment to the next.
- Configuration Center cannot migrate any legacy foundation objects such as pay components, workflows, pay grades, pay ranges, and event reasons. This is despite the fact that the documentation seems to show that these can be moved. More on that below.
- Configuration Center can only send ALL picklists from one environment to the next. EC picklists normally have 20,000 entries so it is not recommended that you move the entire picklist en masse as it is likely that there are some picklists that should not be migrated from one environment to the next, especially since picklists are used by all modules.
- From what I can tell there is no way to migrate some other objects such as error message definitions.
With these findings in hand, I posted a question from the partner portal hoping to get clarification. Was I correct that these are limitations? Can SF provide a list of limitations? I was told that rather than list out the limitations, I should look to the blog below for an itemization for what the tool can do. (I will stop here and ask why Blogs would be referenced as a primary source for anything? If there is information, why is it not in the implementation guide? I will leave that conversation for another day)
So based on SF's guidance, I consulted the blog:
https://blogs.sap.com/2021/04/20/configuration-center-new-way-to-view-download-and-transport-configu...
This blog purports to itemize the items that are available for migration. However, as I dug into this blog, I found it to be (hopefully unintentionally) misleading. Below are 3 examples:
Example 1 Workflows
Great! So I can migrate workflows, right? No. It just means that some of the ancillary configuration elements can be moved. Workflows cannot be moved via Config Center from what I can tell.
Example 2 Position Management Settings
I was pretty excited about this one! Moving the Position Management Settings configuration is something that Instance Sync cannot do today. However, when you look at the detail, it's actually only sending up the Employee Central Setting that enables Position Management. Again, misleading.
Example 3 Event Reasons
This seems to imply that the Configuration Center will transport the event reasons. But it doesn't. What does it send instead? The list of countries. Not exactly sure what countries have to do with event reasons, but I'll assume there is a rationale here.
So in summary, the official documentation lists no limitations and the blog I was told to consult is misleading. Since the documentation on this point is not clear, I will be: Configuration Center is not ready for most day-to-day use yet in Employee Central. If you want to get your feet wet? Great. But for most real-world changes, you need to continue to use Instance Sync for the time being. I have no doubt that in a year or two it will be better than Instance Sync but that day is not today.
The Impact Of Undocumented Limitations
It is disappointing when consultants and clients are left to figure out the state of solutions that have been released into the wild. I'll make a statement I've made on more than one occasion: It is more important to know what a solution does not do than it is to know what it does. Consultants and customers want to believe solutions do what they purport to do. We then invest time into using something only to find out (often late in the process) that the solution is not really ready for even typical use cases. More than once I have been one of the first to implement new functionality only to have to go to the customer late in the testing stage to tell them about an undocumented limitation would require either a workaround or abandonment of the new functionality.
Exacerbating the problem is that most of the time, if the vendor won't publicly identify the gaps users/consultants won't stick their neck out to call out shortcomings. Why? It's risky to provide criticism. First, even if I am right, I can be branded as a troublemaker. Second, It's very possible that my analysis, which was brief, could have misidentified a gap. The reality is that I don't have time to take a day and go line-by-line and figure out what a new tool can and cannot do. But my point is that I should not have to perform this analysis! SuccessFactors should be forthcoming with key limitations. I fundamentally disagree with the approach of "we are putting this out there, the solution will grow, and in the meantime, you can figure out the limitations yourself" employed here.
I just want to be clear that I do not think that this tool needs to be called out specifically. I have seen this practice employed by SAP/SuccessFactors previously. And I'm sure other vendors are guilty of the same. I am all for releasing products and allowing them to grow as long as there is full communication, which is not the case here.
If itemizing the limitations is not reasonable due to the limited nature of the solution, all SuccessFactors has to do is to put a caveat out to say "This is a limited toolset for now. We are putting this out there as a beta and would love to get your feedback". But this tool is no longer in beta and there are no limitations listed. And making matters worse, there is a full-featured incumbent tool, Instance Synchronization, that we are being asked to give up to start working with this new one.
The smart play for me would be just to keep my mouth shut and quietly tell fellow consultants and clients to stay away. I chose to speak up for two reasons.
- Hopefully, I'll save some consultants and customers some time they would otherwise spend trying to use Config Center as a replacement for Instance Sync.
- More importantly, I want to make the point that every time something is released with significant undocumented limitations, customers and consultants get frustrated. And they are a little less willing to adopt new functionality the next time for fear of getting burned.
Solutions don't need to be perfect when they are released. Customers don't expect this and often will deal with the gaps. What they don't want to deal with is surprises.
- SAP Managed Tags:
3 Comments
