Musings on SuccessFactors Documentation From A Self-Isolated Consultant

I started my Employee Central newsletter EmployeeCentralIntelligence.com, almost two years and 75 editions ago, with a mission to make a resource that EC customers and consultants would find useful. I was already spending time "staying on top" of Employee Central developments on a regular basis, so basically I was cleaning up my notes and posting.

I still enjoy putting the newsletter together, but I have to admit that "staying on top" of the documentation gets more and more unrealistic by the day. To be clear, there has never been richer documentation being produced on how a SuccessFactors system should operate than is the case today. Every day I search for answers to my questions and I find them. But with more and more groups getting involved, it is getting harder to stay current. To illustrate the extent of the fragmentation, I decided to spend a week informally tracking the resources I referenced/consulted. The results:

• SAP Support Launchpad (KBAs): 30+ searches, 6 active tickets
• Official Implementation Guides on Help.SAP.com: 15+ searches
• SF Customer Community Blogs (release info): 5 visits
• Reviewed 3 webinars for release info
• Partner Delivery Community Message boards: 6 searches, 3 posts, 2 replies
• SF Customer Community Message Boards: 3 searches
• Implementation Design Principles (IDP): consulted 3 documents
• SAP Blogs site: read 4 blogs
• SAP Jam group on People Analytics: 2 visits
• Influence.SAP.com: 2 searches of enhancement requests

But wait, there's more! Here are other SuccessFactors resources that I consult regularly, but just not in the past week:

• Architectural Leading Practices (ALP)
• HR Process Business Library
• SAP Best Practices
• SAP Partner Edge
• Learning Hub Learning Rooms

Uncle! At some point, it starts to feel like the documentation maze is more complicated than the system it supports. I don't think I am alone in not being able to keep up. I believe that most consultants try their best to stay current, but we all have our "go-to" resources. This means that we're all working with less than the full picture.

Making matters worse, you can sometimes get conflicting answers depending on the source, particularly KBAs, IDPs, Best Practices, and help.sap.com. As an example, I recently submitted a ticket on an IAS issue I was having and the support rep told me to check out the SF Support-created KBA guide on setting up IAS. This is perfectly fine except for the fact that the product team has spent the past month investing heavily in beefing up and clarifying their IAS documentation and likely there will be some variations between the two documents.

Not that anyone asked, but here are 3 changes I would make:

SuccessFactors should decide on "one source of truth" destination for documentation and focus all of its efforts on keeping it current and comprehensive.

Right now it feels like there are 3 different "documentation factories:" SF Product (help.sap.com), SF Support (KBAs), and SF Partners (IDPs). In a certain sense, I see the rationale, but there never seems to be a drive to tie these things together. To me, the logical place for this would be help.sap.com, but my experience has been that only product teams have access to make updates there, and those do not happen frequently. SuccessFactors Support reps, in particular, are not empowered to update help.sap.com documentation. Quite often you'll a sparsely written section in the implementation guide on help.sap.com while there is an excellent KBA written by support on the same subject, because the reps are dealing with real-world customer issues. On numerous occasions, I have requested that the help.sap.com documentation be updated based on the answer I received on an SF Support ticket, only to be told that support reps can't update official implementation guides and that the best they could do was to release a KBA. My question is why the documentation couldn't be more "wikified" with people being able to update the documentation but be subject to product approval?

IDPs are also a great source of detailed information and are generated based on questions SuccessFactors gets from the community. They then work with trusted partners to do deep dives on various subjects. I would suggest that the information generated by the IDPs should be another source for updates to the official product documentation--or at minimum prominently hyperlinked from the official guide to the IDP. That is not the case currently. To be made aware of an IDP, you have to see a blog entry on the SF Community or go to the IDP section of Partner Edge. So, for example, if you're reviewing the official help.sap.com guide on working with pay scales you will have no idea that there is an excellent IDP on pay scale progression the same subject that goes into much greater detail and has better business rule examples.

Have one message board for both customers and partners.

I have been arguing for this consolidation ever since the partner community got its own message board. SuccessFactors employees tell me that the reason for the two separate message boards is to protect partners who need to ask "dumb questions". To this, my answer is that quite often what is one person's dumb question is another's source of confusion. And the best part of message boards is that they allow everyone to benefit from prior questions and answers. At least in the area of EC, the partner boards are more active and have more answers than the customer message boards. The result is that the current structure unintentionally prevents customers from getting at some useful information since they cannot see the partner portal.

Make the investment to continuously update demo systems with the best practices from unified knowledge

The best documentation possible is an environment you can refer to that demonstrates the best practice thinking. Demo environments exist today, but their primary focus is selling to new customers. Implementing customers and ongoing customers would benefit greatly from having a system they can reference. And spending the time to continuously refresh these every release based on the best available documentation would give all customers and consultants a living embodiment of what a SuccessFactors thinks an "ideal" environment should look like. This could take the place of the Best Practice builds as the demo systems have the benefit of being able to have a robust set of data that really aid in demonstrating how the system should operate. Consultants can still download the data model, business rules. etc. Best of all, it becomes much easier for consultants to know and be held accountable for what an implementation should look like and focus their documentation on any deviation from what is considered best practice.

Conclusion

I want to reiterate what I set at the top of this blog, which is a lot of people in SuccessFactors and beyond that are producing a lot of great content. I just think systems need to be put in place to ensure the dots get connected. Comprehensive, clear documentation helps everyone: consultants create fewer tickets and produce the best implementations possible, customers are better able to sustain their own systems, and SuccessFactors ends up with more happy customers to reference. And it will give me more time to devote my attention to things other than documentation, which will make me much more fun to be around once dinner parties start up again.