Okay – so I’m supposed to be doing something else right now, but a) I’m procrastinating, b) I just got off a call with a whole bunch of SuccessFactors integration “experts” and I want to show that I haven’t completely lost touch! And c) I’ve finished Witcher 3 Wild Hunt and all the add ons and played far too much Civ6 so I really needed to do something else (which wasn’t the thing I was avoiding doing in part a).
So, I thought I’d share a teeny tiny simple integration that I helped a customer build the other day. Yep – I didn’t build it – I helped the customer do it (a functional SuccessFactors admin) via a web meeting.
Updating data in SF WITHOUT using a workflow just simple integration
It came about because we had just updated from old and honestly less than perfect Boomi integrations to newer (and still not perfect, but better) SAP Cloud Platform Integration based integrations. One of the things that was “fixed” was that leave records in SF and SAP were now being kept in sync. So an old process that they had running in SAP that was updating SAP leave records without updating the SF record was no longer working. Well, truthfully, it did work, right up until the next sync run happened and then the record got updated back to the SF state.
Requirement(ish)
The functional requirement was based on a process this customer has. They allow managers to enter a “unexplained” absence type for employees into SuccessFactors in the case that an employee is a no-show for a given day. When the employee returns to work, they have the option to change that absence type to a personal leave (sick leave or carers leave) or mark it as annual leave, or however it needs to be handled. But if they don’t update the record within 14 days the leave type is automatically changed to personal leave without medical certificate.
Design
On the basis that “Any sufficiently advanced technology is indistinguishable from magic”
I present how we got it to work again in my bad whiteboard drawing style. NB payroll is shown as a little black box because you really don’t want to look in there, and I clearly do not have enough skills with drawing to represent Pandora’s box.
So I’d like to take the time to explain how we got the “Magic aka Integration Center” bit to work. (Yes I know that there are two spellings for Centre/Center and really I don’t mind. If I did I would blame the US, but they’re in a world of hurt right now, so let’s be nice).
Making the Magic happen
In Integration Center we created a new integration:
Chose the “more integration types”
And then chose Scheduled SuccessFactors to SuccessFactors OData v2
Chose the Employee Time entity
Then simply dragged and dropped the external code from source to destination, fixed the time type to 0200 (Personal Leave)
And set the operation to “Update/Merge” (which is a personal bugbear of mine since the HTTP operation should really by “Patch” not “Merge” but that’s OData v2… <sigh>)
Now if we were to run this now it would transform all leave record in the system to time type 0200 – which would be bad… (with great power comes great responsibility Peter!)
So next up let’s restrict which records should be selected…
I’ve only set up one “Unexplained” absence in the system – has time type of 6666
Now we only want to update entries that are time type 6666 and creation date is 14 days in past (I’ve used 14 minutes for this example because waiting 14 days seems a bit excessive for such an unpolished blog post)
Note that date filters have a very useful “relative date” option.
Now jumping back to the configure fields screen and you should see only one entry… (NB if you choose created DATE rather than created DATETIME, just taking 1 min off actually takes you to previous day so be careful what you choose!)
Now if I wanted, I could schedule the job to run daily:
Then just set the schedule and go for it!
But to be sure it’s working, I can actually just run it in preview:
And it works!
Entry updated to personal leave
So simple, yet so powerful!
Usual disclaimers apply – and especially so given the whole Spidey superpower unleashed here. You can really muck up your data doing stuff like this… DO NOT TEST IN PRODUCTION!
Enjoy. Don’t be afraid to give it a go! I’d advise, just go out try it. You learn so much more that way rather than asking other people to figure things out for you!
Okay, even with the number of diagrams in my last post, there was still some confusion. So, I’m going to try to make it totally clear. Emphasis on “try”.
Regression Testing isn’t just about regression testing one part of a solution
Firstly, I got some feedback from SAP Support when I tried to raise this issue with them. They didn’t seem to understand my concern that I tested the whole recruit to hire to fire employee life cycle every time that SAP released new functionality for SuccessFactors in the preview environment before it got released to the productive environment. This was because:
“Since IAS productive and test instances are of the same version, there is from IdP perspective no difference at all.“
…
“As already mentioned above: IAS test- and productive instances are of the same release. There is no such thing as a preview environment for IAS. Thus again one single IAS tenant will be fully sufficient to handle the described scenarios from IdP perspective“
I’m not sure how I can make this clearer. But, yes, I do want to test that during the preview release update period the changes that SuccessFactors make do not impact the provisioning and login processes that I have configured in IPS/IAS. I also want to ensure as well as ensure that these are working in the non-prod environment so that if I push up a change to fix a release impact, it doesn’t break stuff. I’m confused how the Identity services teams seem to think their solutions works in isolation! If it isn’t for the systems that use their services and provide the user details the solutions aren’t worth anything!
How does this all look if we try to connect it up?
Okay – here’s a relatively complex diagram. It shows how you’d have to wire up the provisioning and authentication trust when using more that one SuccessFactors system with a single IAS.
But there is the slim possibility it could work!
And it could work provided that you:
Did some configuration in the IPS and IAS that SuccessFactors has not at all been documented for customers
that populated userid into different custom attributes of the IAS user record per system
then used that system specific field in the assertion sent to the different systems.
AND – never maintained different employee attributes for the same email address in the two systems (if you don’t want the system to get hella confused.)
Unfortunately that’s about as likely as me winning the Powerball lottery. Whilst the first point is terribly technical and pedantic (therefore will be loved by half the people I know and hated by the other half) the second point pretty much means this is never going to happen. The reason for the second restriction is that you cannot have the same email address against multiple “user” records in IAS. Whilst through some technical wizardry I might get the same record to point to two different system ids, whether it is active or inactive is a non-system specific piece of user data. What name that user has is a non-system specific piece of user data.
So assume I do have the same email address assigned to an employee in both systems A and B. Terminating that employee in system A will cause a delta in the employee record that will get picked up by the IPS and deactivate the user in the IAS. Even though they should be active to be allowed to log in to system B, they won’t be able to as they are now “inactive”.
It is possible that customers will just decide that they will ensure consistency between user records in different systems, use same name, have both active, have both inactive, but I very much doubt it.
Likewise not using the same email address for employees in both systems is going to be hard (not to mention hard to track if it mistakenly happens).
Would be nice, but unlikely
In my previous post, I assumed that the previous scenario (especially as it involves undocumented configuration) would not be customers’ default. There I assumed that customers would use the default configuration that is deployed when a customer implements the SuccessFactors IAS “upgrade”. That then allows for all sorts of mischief!
How to abuse authentication when you control the data it is based upon.
Let’s have some fun. Assume that default IPS configuration is being used and the employee records from systems A and B are both trying to update the IAS user master record. Assume system B contains sensitive payroll data (for example it is a copy of productive system). Only Annie Admin has the roles in system B to see this data. I, Chris Creative, have access to system A where I’m doing some project work. I have a role where I can hire and fire employees (tends to happen in HR systems!)
I firstly terminate an employee with Annie Admin’s email address in system A. If there isn’t one, I’ll just hire her then term her.
This will trigger the IPS to update the IAS with the user with Annie’s email address as inactive so Annie can’t log into either system and stop my nefarious fun.
Then I hire a new employee that has the same personnel number as Annie had in system B and put a newly generated email address (that I have access to) against the employee’s record
I get emailed by the IAS that I have a new user record set up 🙂 what a cool system! I set/reset the password.
Now I can use this email address to access system B and it thinks I’m logging in as Annie! Which is awesome as when they try to trace who downloaded all the payroll details from the system the audit logs are going to clearly point to Annie’s user! (Okay yes a bit of further checking and someone might see that it was my IP address, but I can hide that using a VPN, the audit logging in IAS is hard to get to (API access only) so going to be hard for them to find the random gmail address I made up and trace it.
I access a bunch of data I’m not supposed to
I go back to system A, change the email address of the fake Annie back to her email.
She gets reactivated
I just got away with accessing a system that I had no rights to access because I had rights to another system that was provisioning the same authentication system.
Are you worried yet?
Can you see now why I’m a little worried about this setup? This is why I also assumed that to prevent this sort of thing happening, most organisations if forced down the path of using just one IAS will choose the most secure SuccessFactors system to provision user data to the IAS. But that, as I wrote about in the previous post will cause a bunch of other problems.
Simple solution
In case it’s not obvious enough, there is a simple solution. Provide another IAS instance per SuccessFactors instance that a customer has.
So, firstly, at this moment in time it feels a little petty writing about this. The world is just starting to realise how huge a problematic space we are in with COVID-19. So I wish all of you out there reading this, health and the wisdom to look after yourselves and others. So, now back to me being needy.
tldr;
SAP SuccessFactors are only offering customers one non-prod IAS system. One non-prod IAS is not enough. Read more to understand what that is and why I think this is a mistake.
A new service to support new functionality
Recently SAP SuccessFactors announced that they are going to move all customers to a new platform authentication solution which uses SAP Cloud Identity Authentication*. This new background service is a requirement to use the new People Analytics that use SAP Analytics Cloud and is also required to use new internal facing Career Site builder functionality. In short, to take advantage of some of the newest and coolest looking features of SuccessFactors, you’re going to need to implement this!
*There’s a handy overview video (strangely enough not behind SuccessFactors community wall) that explains in detail what SAP is doing, it’s a little more in depth than the detail I provide in this post, it’s not bad although very detailed.
Why are SAP SuccessFactors doing this?
Honestly, this is a good move. Authentication is a common problem in all cloud based solutions, so why not have a single service that can be leveraged by all SAP solutions to solve this? Customers get the benefit of multiple development teams within SAP all pooling to produce a better product, SAP gets the benefit of reducing cost of having to maintain and upgrade their authentication solutions for each cloud product. Win – Win!
Not often the balance seems to favour both sides!
It’s not yet a requirement for customers to migrate to this solution (and yes for many customers this will require some work to implement), but in order to take advantage of several new SAP SuccessFactors functionalities, customers are going to have to move. So I’m pretty sure that SAP will get close to its goal of migrating by end of year (although possibly with a covid related bump in that progress).
“Our goal is to have customers migrated to SAP Cloud Identity Authentication (IAS and IPS) by the end of 2020. This is not a “forced” migration, we are just encouraging customers to migrate. At some point all customers will need to be using this authentication method, that date is not yet determined. “
from SAP SuccessFactors Community, Platform Resources Blog
However, in going through the process to migrate some of my own systems, I’ve discovered a bit of a problem. I’ve tried to raise this multiple times, but so far, I just don’t seem to be able to clearly articulate why this problem is so important. So, I thought I’d try putting together a simple blog post with LOTS of pictures. Hopefully more pictures means easier to understand and then we can get somewhere!
Background – How does it work?
Okay, before diving into the deep end, it’s probably worth trying to articulate what on earth this SAP Cloud Identity Authentication is, and why I’m so happy that it’s coming.
Simple how to log on process
So, here’s how it works in general.
Happy SuccessFactors user uses their computer to
Access SuccessFactors website, which
Redirects them to their own company’s identity provider (IDP) which asks them to log on (or possibly realises they are already signed in and does single sign on. Which then
Sends them back to SuccessFactors having verified that they are a valid user and they can access their SuccessFactors system, so
The Ecstatically Happy SuccessFactors user is even more happy!
Pretty simple really! There’s some technical stuff like SAML2 assertions and stuff that happens – but generally the experience and security are what matters.
Importantly, SAP SuccessFactors aren’t really aiming to change any of that experience, there just a small technical difference. In between steps 3 and 4 there’s going to be a little more going on under the hood.
Steps 3 and 4 of our previous diagram are replaced with 4 other steps. Quite simply SAP Cloud Identity Authentication Service (IAS) becomes a middleman to/from SuccessFactors and the Corporate IDP.
SuccessFactors sends unauthenticated requests to IAS.
IAS redirects request to IDP for authentication.
IDP tells IAS that user is identified and correctly authenticated
IAS tells SuccessFactors that user is identified and correctly authenticated.
There are a few benefits here. The SAP Cloud IAS is set up to be maintainable by customers. Whereas setting the details of a corporate IDP into SuccessFactors was/is restricted to SAP and certified partners, using the IAS is something that most customer’s technical teams should be able to manage. (I’ll caveat that with note that I expect that most customers will probably get their implementation partner to guide them through the initial setup. But at least it is something that customers can do, if they want to.) SAP SuccessFactors automagically set up the link between SAP SuccessFactors and the IAS.
There are many options to be able to configure the IAS to do some nice things, setting up rules for access, making login screens pretty, etc. It’s a good tool.
It is important, however, to understand that the IAS isn’t just a simple pass-through proxy service for authentication, it stores a list of all active users. A user MUST exist in the IAS in order to be able to log on to SuccessFactors.
So, what’s the problem?
Well so far everything seems hunky dory, no? Well, that’s probably because I’ve just talked about the productive use of the solution (which to be fair is what most people care about.) However, for many customer non-productive environments (and even some productive ones!) a corporate IDP and single sign on is not used.
Simple password-based access not using a corporate IDP
Uses browser,
Logs on with username/password (stored in SuccessFactors)
Is happy
This scenario is updated also with IAS in the picture.
Can we just assume that you’re as tired of reading numbered lists as I am of typing them? No? Okay – just to be complete:
User bounces to their laptop…
Uses browser to access SuccessFactors
Which redirects them to IAS which asks them for username and password (as no corporate IDP configured)
IAS tells SuccessFactors that user successfully identified and authenticated.
User has great time using SuccessFactors without SSO or a corporate IDP
There is some great functionality that can be leveraged here too! SAP Cloud IAS can implement multi-factor authentication – pretty damn good to have that available without having to use corporate IDP!
Sidebar – there is an IPS too
Yes, sorry more terminology! The way that the IAS works it needs to have a list of users provisioned into it. It doesn’t just use the list of employees that are in SuccessFactors, these need to be populated into the IAS.
The IPS reads SuccessFactors regularly to find any changes to employee/user records
It passes any details if finds to the IAS which updates its list of active users for SuccessFactors (and potentially any other system that authenticates against it).
Now that might sound like a retrograde step – it means that we need to provision (yep IPS stands for Identity Provisioning Service) users from SuccessFactors into IAS on a very regular basis. But, realistically, there are very few productive use scenarios that require a new employee to have access to the SuccessFactors system instantaneously, a delay of an hour is normally manageable. And there are ways to make that sync happen faster if needed.
Again, this seems all to be good news! There are a few minor niggles. For instance, the IAS must keep a list of usernames and email addresses in order to allow it to function. One additional restriction is that all users must have unique email addresses (you can’t set all the non-used users’ emails to dummy@dummy.com!) Again this doesn’t seem to be much of a problem. Until one considers that many customers have more than one non-productive system.
There can be only one!
I was so tempted to put a Highlander meme in there… But I didn’t because it might distract from the seriousness of this next bit – which seems to be the official SAP position at the moment.
” SAP is offering free [IAS] licenses to SuccessFactors customers for the purpose of logging-in to SF; they will receive one production and one test instance (by region). “
SAP SuccessFactors IAS FAQ, highlighting and info in [brackets] added by me
SAP will only provide customers with one IAS tenant for their productive environment and one for their non-productive environments.
Why is this a concern?
This seems to be the bit that I’m having trouble explaining to people, so I hope the following diagrams and explanations help.
For many SuccessFactors Employee Central (Core HR) customers they have been provisioned by default with three instances. Customers can use them however they like, but I tend to advise people to do the below:
Note that these systems are very often linked to payroll environments that reflect similar levels of detail to the productive environments. As such, the levels of control of access are very important. This is personal and private information and needs care and attention!
However, very often one of the systems will have anonymised data, or even just made up data, and be used for prototyping and building solutions. Generally in this system users may be given access to areas that they don’t normally have access to. Training and/or testing may take place. The key thing is that users may be running scenarios with different access levels than normal.
It’s important to note that whilst there is clearly an overlap in user records between all three systems, there are plenty of users in both non-productive environments that don’t overlap in normal usage of these systems.
Again, so why is this concerning?
Well, to reiterate, SAP have said they will only provide as part of customers’ existing subscriptions, two IAS instances. One for productive use and one for non-productive/test environments.
The non-productive IAS must provide authentication services for both non-prod environments. However, the feed that populates the list of users into the IAS can realistically only come from one of the two environments.
I’d better make QAS my source of user data then
Due to security concerns for data access, I must then make the source of user data for the IAS the QAS system, where I have locked down user access. Otherwise, if the source of the user data was the test system, then a test user could update a user in the test system records to have details that could allow themselves to log on to the QAS environment and see data that they were not supposed to see. That can’t be allowed!
Real email addresses at a premium for testing, double handling.
It will be quite some hassle to maintain all the Test system users in the QAS system, but it could be done. However, it may be very difficult to test scenarios that rely on real email addresses. Because the email address must be unique in the IAS, it won’t be possible to swap emails around easily. This becomes especially problematic when email address is used to authenticate users to downstream systems (particular cases where I have seen this occur are SSO into SAP ERP systems, where email address is used as the unique identifier.) Changing an email address to allow testing of a process may mean creating a new employee in the QAS system and reassigning email addresses there in addition to updating the test system.
But hold on, what about regression testing?
However, during the 6 monthly release cycle, there is a need to test all the new SAP SuccessFactors functionality. This needs to be done in the preview environment. So perhaps during this period I lock down all access to the preview environment, make user access as per the QAS system? Then I switch my IAS source to be the preview environment? This has some problems associated with it too. It really restricts how I can carry out my regression testing and who I can use to do it. But sure as a very sure thing, I will want to test out user provisioning and definitely want to check that the configuration I’m using to populate the user list into my IAS from SuccessFactors hasn’t been impacted by the half yearly release.
So where does this leave us?
Very soon, with the release of SuccessFactors embedded analytics (People Analytics), more and more customers are going to want/need to implement SAP Cloud IAS within their SuccessFactors environments. I would imagine that due to the overheads that I described that many customers would opt to purchase an additional subscription for another non-productive IAS instance. If I think of the cost/overhead of:
maintaining all non-productive users in pre-prod (imagine having to hire someone in the pre-prod environment just so you could test a hire in the test environment!)
Separating out test system users/data from pre-prod environment to ensure regression testing payroll changes.
Migrating IAS and IPS (tool used to synchronise user record to IAS) configuration from one system to another to enable release testing, then flipping back if urgent production support testing needs to occur.
Restricting release regression testing to only those users that have pre-production access and only to their regular roles.
Then I think I can see the cost benefit of purchasing an additional IAS system to handle that. But I really don’t want to be forced into paying additional subscription to handle a scenario that works just fine right now.
It seems that the balance has shifted and not it a good way for customers.
Given that when I raised this point in SuccessFactors community site I was told that:
…By design, you don’t need a 1 to 1 relationship between SF instances/tenants and IAS.
IAS is designed like any other Identity Management product to handle logins for many different systems. Customers don’t buy a new copy of Ping Identity or Microsoft Azure for every application they use it for. Your IAS configuration will control which SF instance users log into.
Additionally, having the 1:many approach makes it a lot easier to manager [sic]. If you had multiple copies of IAS/IPS you would need to figure what is connect to what every time you want to manage anything. When you re-use the same IAS for many applications, you only have to configure one time and then re-use them. ie…Password policy settings, Corporate Identity Provider connections etc. The corporate IDP is a huge one since you have to work with your internal SSO folks any time you change anything there.
I think there is a disconnect between how some SuccessFactors product managers think customers are using their product and how it is being used. Many customers do not use SSO into their non-productive environment by design!
Next steps
I really hope that by spending the time to put this post together I can raise some awareness of this problem before it becomes a bigger issue for customers. Ideally, I’d love SAP SuccessFactors to re-evaluate their stance on providing only one IAS instance for all non-productive SuccessFactors instances. It should clearly be (in my not so humble opinion) one IAS per SuccessFactors instance. (on a technical note, happy for just one non-prod IPS). Let’s see. If you’re reading this and you have some influence with SAP SuccessFactors it would be great if you let me know what you think and perhaps let others know too.
Last thought on solution parity
Finally let me leave you with one last diagram/thought…
I love working with the SAP SuccessFactors software and I think that the IAS is some great functionality. However, no new functionality that replaces existing functionality that a customer has should ever require them to purchase additional subscription to retain parity with their existing solution.
P.S. there’s a follow up post to this one to clarify a few things – How to break a shared authentication solution where I put my evil hacker hat on and give and example of why this could be very ugly for an organisation.
Just some very brief highlights and musings from the lounge in LAX whilst I wait for my flight home to Melbourne.
This was the eXperience SuccessConnect, there were X’s everywhere! The amount of airtime that Qualtrics and experience management got may well have equalled the amount of time that the SuccessFactors product was discussed.
My SuccessConnect really kicked off with the Monday partner briefing and meeting up with Sylvie Otten and introduced to Micheal Grimm from Ingentis. Was good to start off the event with a good moan about the state of CF vs Neo when it came to SuccessFactors extensions. Sorry Sylvie – I earned my namesake.
At least she was smiling in the photo!
Next up was the partner briefing – after having made the mistake of sitting near the front last year at it being the most boring multiple hours of the conference, I sat at the back so I could sneak out rather than pass out with boredom.
I was wrong.
David Ludlow completely creamed it with his update on roadmap and recent changes. That was probably the best 20mins of the entire conference. Wish I had sat nearer the front! Although have discovered that taking photos of slides in SAP’s newly preferred dark theme really doesn’t come out well, the black comes out browny grey – doesn’t look so cool… 🙁 But I got the slide deck – gold!
There were many cool things in there, but the new UI being proposed for the user landing page was probably the most exciting bit – which is why David didn’t say much about it, but left that for Amy the next day at the keynote.
Lots of debate about this new conversational AI based UI. With the biggest one being, there better still be menus and some way i can add a link to view my payslips, and apply for leave with one click without having to type in “view my payslip”.
We’ll see how it develops as looks like planned delivery 2020 – but I’ll bet on it not being GA before next SuccessConnect. Perhaps beta with a couple of customers… lets see next year.
After David’s excellent presentation I got to catch up with the team of analysts and media folk who’d had a briefing that day. Josh Greenbaum was holding court and had some interesting comments around SAP’s strategy with payroll, but the wine and food was excellent and I left with some of the folks there to go to the exhibition show floor and do what I was supposed to be at the conference for (not chin wagging with analysts!)
I was here at SuccessConnect to sell a SAP CP extension for SuccessFactors that me and my team have built – it provides EHS functionality embedded into SuccessFactors. It’s pretty cool! But I would say that!
I have discovered that I sell much better with a glass of wine in my hand…
After that it was to Jewel nightclub to the Kronos and Rizing party (not sure I really should have continued drinking, next day was hard work!) But did get to meet up with Sherryanne Meyer which was nice.
The next day was lots of water and the keynote.
Have to say, I love the moments that matter idea. as in consider where you are putting your effort in making certain processes work better. It’s probably much more important that the initial day one experience for an employee is better than the process they have to use to apply for leave. They might apply for leave hundreds of times, but they only have one day one and it will be a much bigger impact. Think about the return to work process for return from parental leave, make that a great experience don’t worry so much about timesheet entry….
However I heard the term FAR too over used during the conference and used outside of the context i just described.
And then the keynote just went to “eXperience”. It was wow, everything was about HXM or Human eXperience Management, not Human Capital Management. Look, I dislike the HCM idea of treating employees as “Capital”, that’s not what we try to do, but still there is a whole bunch more the the successful running of employees in a business than just looking after their experience!
I observed cynically to someone (the night club from night before possibly didn’t help my mood) that it seemed that the SuccessFactors exec team had all been given bigger KPIs to sell Qualtrics than they had to sell SuccessFactors.
After the keynote were lots of general sessions including loads of roadmap sessions! The conference team really listened to the customer desire for roadmap sessions and most were repeated at least one. Even better the sessions were short on presentation and long on questions. This is why people come to conferences rather than reading the slides at home (and without having to fly stupid distances around the world). So SUPER KUDOS to the SuccessFactors team, your roadmap sessions were AWESOME! I had lots of fun in one run by Mark McCawley who I meet for the first time and leaked some news that I’m hoping we can reveal soon that will make many customers very happy!
Saw mention that instance sync tool will allow copy back of employee data from prod to non-prod systems (without full system refresh) allowing for trouble shooting of issues in test environments – this is awesome and will be a huge benefit for customers. When you look at the list price that Accenture were/are charging for a SAP CP tool that does similar thing, you can see how customers were really wanting this functionality!
Talking of the SAP App Store and SAP CP extensions, they were highly visible this year on the show floor and customers were clearly interested!
Final keynote was more eXperience Qualtrics puff along with 3 partner add on solutions, and a strange plug for SAP.io which I’m pretty sure the audience didn’t care about. Much disappointment that non of the partners on the stage with SuccessFactors add ons were using SAP Cloud Platform – a real lost opportunity to showcase the power and benefit of having extensions that look like they are just additional modules of SuccessFactors, a functionality that SuccessFactors has that is unique – I’m afraid integration to ServiceNow isn’t really that unique…
Last day and the team:
went to the golf driving range, where I discovered I’m not terrible at this golf lark, but not good at it either. Was fun!
Anyway – flight about to be called.
Was great to be at SuccessConnect, think it would be good for the SuccessFactors exec team to perhaps take a moment to listen to the SAP Mentor feedback – perhaps we can arrange something for next year?
An empty road with a whole bunch of speed bumps. I’m afraid that’s what today felt like. It’s kinda weird starting off a conference without hearing the keynote to set the tone. Even with SAP conferences like TechEd we have “pre-conference” days – thanks ASUG! But today was part of the conference, and it didn’t really feel like it.
An example of the bumpy road was having a session today on the new support model for SuccessFactors, but without mentioning the SFXpert program. It was kinda weird – but apparently Mike Ettling will talk about that in the keynote tomorrow, it’s a little confusing.
Moreover, there weren’t an awful lot of people here. Which in someways is pretty good, it means that we’re able to have comfortable conversations, no running around with microphones to ask questions. But it certainly seems that running a SuccessConnect in Singapore may have reduced the number of Sydney attendees. I’m not sure, perhaps tomorrow will bring more people? It was a big ask to get people to come for a whole day for 3 sessions.
Would love to know where we’re at with that total – hopefully we’ve got above a few thousand dollars by now.
So a few bumps, a fairly empty road, but the way ahead looks clear, and the weather is glorious. I look forward to tomorrow. I just hope that the panel session with David Ludlow goes well. 🙂
(Mike Ettling explains SuccessFactors new commitment to putting customers first)
So I’m in the lounge at LAX – the new OneWorld business lounge – it’s loads better than the old Qantas lounge, they have craft beer on tap for a start, which did lead to rather a few posts:
Which weren’t particularly related to themes I normally post on, but nevertheless probably tell you something, I’ll leave this as an exercise to the reader to speculate on what.
So whilst I’m nice and relaxed after a nice shower and looking forward to heading home, I thought I’d capture a couple of things that happened whilst I was at SuccessConnect this week, and hopefully this will also remind me to expand on them at a later time.
Firstly – customer first
The commitment by SuccessFactors to publish a roadmap to customers is a big win. And It’s not just a win for customers. As a partner it’s much easier to advise a customer when you have a good understanding of what _might_ happen in the near future. By making as much of the solution as possible accessible by the upgrade centre rather than provisioning (an ongoing effort) it removes from customers the need to engage an SI partner for what may well be just an administrative task. Allowing customers to attend the same training that partners can attend is also a great thing – so now there is a real possibility that customers can do some of their support in-house.
Why, you might ask, am I cheering this as a good thing? I am one of those partners who previously customers had to rely on to make these changes. Well, it’s really because I don’t like doing boring stuff. If as an SI all the work I do is very simple, then customers can be a little resentful for paying me as much as I would like to be paid. I see this as an opportunity to get rid of the boring work and instead focus on bringing real value through expertise. We shall see, but I’m hopeful that this is the path SAP envisages as well.
SAP a SuccessFactors company?
With Rob Enslin opening the conference, I got a real feeling of SAP being a full part of the conference, and not it being a SuccessFactors as a separate company anymore. That said, all the “Cloud DNA” was still there and it was interesting to see Lars make a guest appearance. The reaction from the SuccessFactors staff to seeing Lars was remarkable, it was all a surprise, and a nice one for most. However, Fiori making itself felt in the UI development pipeline amongst other “Simple” things shows that the “DNA” exchange isn’t just one way.
Phased releases
The public announcement of a phase released of functionality, with updates being released a month earlier on the test instances of a customer is great news. This will help extension developers hugely (although ideally I’d like access to the update another few weeks before the customers get it in their test systems, but can work with this idea!) Customers too have the ability to check out any mandatory (although there are few of those) updates before they get deployed. All in all a great step forward to helping customers manage their solutions – and the spontaneous applause from the audience when it was mentioned shows it’s not just me as a developer that appreciates this.
Righto, that will do for now, Mike Ettling’s flight to Sydney has already left, and mine to Melbourne is going soon. I’ll be catching up with him and the team again for the Sydney version of SuccessConnect, but I’m so glad that I was here this week in Las Vegas, it has been great.
I was very interested to read some links that Naomi Bloom posted about how Workday have moved to a continuous integration deployment model rather than a phased release.
As developer, I love the idea of continuous integration, having a set of tests that can automatically check whether the code I have built will cause an issue in production and then allow me to move it up to prod immediately. It fits with TDD and all the other cool things I want to do. Awesome!
If I were writing code in the internal development teams of Workday or SuccessFactors, I’d want the software to be CI.
However! As a developer of extensions to one of those platforms, I couldn’t think of a worse option! If you look at the “disadvantages” section in the linked Wikipedia article on CI, you’ll notice that one very important thing is to have lots of good automatic test scripts. The problem is, a vendor can only possibly run their own test scripts, they can’t run mine. (Perhaps they could run mine if such an API was built, but could they justify not deploying to prod because a little used partner extension failed a script?) So what if some change that the vendor does breaks a behaviour in my code? Well, that’s bad for me. I’d better hurry up and fix it, because all my customers are now with broken code, and the first I found out about it – when it broke. And likely I’m not going to find out until I have one of my customers complain – unless I have proactively set my test scripts to run every hour and send me a message when something breaks, in which case I’d better be ready to do emergency support 24/7. Yeah, just what I want. NOT!
This would be a huge burden on a extension provider, you wouldn’t have a stable platform to build on.
With SuccessFactors being on a phased release rather than continuously integrated to production, it is much easier for me to join in with the testing of my solution before it hits the market. I know that my customers aren’t going to get a nasty shock because something suddenly breaks/changes behaviour, because I have a window to test that before it impacts them. I also know when that window is going to be, so I can plan around it and allocate my resources. Whilst the solution might be wonderfully cloudy and elastic, my skilled pool of extension developers is definitely less cloudy and more finite and fixed.
Now it might be possible to allow partners to have an early access box, and perhaps delay CI deploys to production by a week or so to allow partners to test their code. But that is one hell of an effort that you’re demanding of your partners to do that. And as one of those potential partners, I can say I’d be thinking very long and hard about the risk you as the vendor are putting me at, and probably would decide not to go there.
I think, that in a world where purchasing 3rd party add-ons for your cloud platform will become the norm (allow me my dreams please). And where the power of the platform is driven by these add-ons/apps, having a phased release makes sense. How cool would an iPhone be without any apps from the AppStore, how good would an S5 be without apps from Google Play? They are both great devices, but they are awesome when enhanced by external developer partners. These mobile solutions have phased releases. It’s not because they couldn’t have constant updates, the tech is easily there for that to happen, but because in order to sustain the applications/application developers that make them so cool they need to provide a stable platform.
I’m really glad that SuccessFactors provides a stable environment for me to build on, as I am convinced that HCM SaaS has a huge potential to be enhanced and extended to the better use and consumption of businesses. It’s a real strength of the solution, and I am very happy to be play a part this story, and that SAP and SuccessFactors are carefully considering the needs of the development partner in this scenario.
All that said, it would be cool to be developing in a continuous integration solution, but just not for the partners building on your solution.
And of course I’m all worked up. Why? Two reasons.
Firstly, I strongly disagree on the premise that performance management actually achieves improvements for the employees that are being “managed”. This is using Steve Hunt’s own definition of performance management:
Standardized and defined processes used to communicate job expectations to employees, evaluate employees against those expectations, and utilize these evaluations to guide talent management decisions related to compensation, staffing and development.
This has nothing to do with motivating and improving employees. It’s all about figuring out what is the smallest amount you can get away with paying your staff.
A process that can actually help employees improve is by working with them to find out their interests, find out what they want to do and shape their work around that. This isn’t the world of Gen-X and Boomers any more. People are far more interested in making work part of their life and life part of their work. Will they do that if there is a regimented process that is going to measure them against the cookie cutter mould? No, they won’t. Because no employee is exactly alike and no employer that wants to get the best out of their employees is going to manage that by trying to shape an employee to the employers expectation. We need instead to understand the great whole of the employee’s values and use that to motivate them. An employee that is doing what they feel is valuable and feels that the company supports them in this is far more likely to perform well than one that does not.
We have the tools (in a creepy big brother kinda way) to be able to analyse far more than just our employee’s achievement of our stated corporate goals, but also the interests, engagements, networks and influences of our employees. By better understanding our employees, and then aligning our business goals with their goals, we stand so much more chance of motivating and retaining talent.
Remunerate at the market rate for the skills that the employee possesses, if they gain more skills then pay more. Or if those skills have nothing to do with your business, don’t try and hold on to someone who would be happier elsewhere. Likewise, if the desires of the employee do not align with your corporate goals, don’t attempt to force the employee to comply, you are both better off without each other. Have the frank discussion that their desires and your goals don’t align at all. If their goal is to sit and eat chocolate and drink coffee all day and you don’t have a coffee and chocolate tasting role in your company, then it’s probably not going to work out. But it is good to know this – it’s time to move this employee on. Not because they don’t do what they are supposed to do, but because they have no desire to be doing it. Be frank, you can’t get rid of them if they are doing a reasonable job, but they will never be stellar unless _they_ want to do the work.
Now, I’m sure that this approach isn’t going to work in many, if not most, industries. If you have a load of jobs that people will only do if they are paid enough to suffer through, then this approach will not work. In this case fall back on Steve’s approach, just realise you’re very unlikely to develop or retain any talent.
However, if you are in an industry where people (or at least some of them) work because they love doing the work and are enthused about being the best, then I think my approach has some real advantages. Of course you will get and hire bad apples. This is where I believe performance management comes in. You now attempt to manage that person out of the company and ensure that you are not at legal risk by following a clear process. I’m sure there are risks in only performance managing those you’d rather have leave the company, but there are certainly rewards too.
And now to my second point of why I’m unhappy with this article. It was written by someone with the job title Senior Vice President of Customer Value at SuccessFactors/SAP Cloud HCM.
If this is what SuccessFactors believes will drive more customer value, then I’m very worried that innovative and alternative approaches to making talent management work are not likely to get a great reception.
I strongly agree with Steve that we need to find out and measure how well our people are doing, but that does not need to be against a defined set of company goals, but against an slightly less well defined set of individual personal goals that the company can hopefully align with and benefit from. I believe that the next step for talent management solutions like SuccessFactors is to help employers with the analysis of who their employees are and what they want. Then use that information to help align both the business’s needs and the employee’s desires. It’s a huge technical challenge but we have to start somewhere. By at least acknowledging that there might be better ways of doing things rather than just dismissing them, we’d be making a first step in the right direction.
Companies that start to embrace the holistic view of the employee rather than the company centric one will, I believe, start to reap the rewards.
I could well be just dreaming, but at least I’ll be dreaming with some of the most motivated and enthusiastic people around who are all trying to achieve their goals in my company.
What does your company’s organisational chart look like?
a) the Eiffel Tower,
b) a bowl of spaghetti?
SuccessFactors Professional Edition – a thought provoking trial
I’ve been trying out the SuccessFactors Professional Edition (SMB market) software recently (and no, this is not a review of it, that’s coming later (maybe).) It gave me a moment’s pause to think. Does the organisational structure at my company actually resemble a tree (an upside down one I guess) at all? The SuccessFactors software has a great organisational structure visualisation tool (far nicer than the Nakisa one IMNSHO), but it’s all about visualising a traditional hierarchical organisational structure.
Different types of structures
At the same time I was thinking about this, I happened to read the supposed “Valve Handbook for New Employees“. On page 4 (I’ve included the link, if you haven’t read it, I can recommend it, fascinating stuff and far more than just the bit I’m talking about here) it describes the structure of the organisation.
It makes a point:
“Hierarchy is great for maintaining predictability and repeatability. It simplifies planning and makes it easier to control a large group of people from the top down, which is why military organizations rely on it so heavily.”
Like Valve, I don’t see the organisation that I work for being particularly militaristic. I grew up as an “army brat” and therefore have a very healthy (in my eyes) disregard for any kind of imposed authority. Someone telling me that I must do something in a certain way, is almost a guarantee that I’ll try to find a different way of doing it. I try to treat the people I work with like I would like to be treated. Telling someone to do something is pointless, explaining to them why they should do something – that’s more like it.
I’ll digress from my main point here for a little bit, because a random memory has just sparked, and it’s sort of relevant. When I was a new grad starting out in the big wide world of SAP HR consulting all those years ago, my boss at the time hauled me out of the clients where I was shadowing and learning, and into the office. For one week I helped the office admin team file expense reports, collate time sheets and put together invoices After that, although I may never have been the best at getting my expenses in on time, when they did get in, they were very clearly and neatly arranged. Why? because I had learnt that doing so was a simple task for me, but made the life of the admin person so much easier. Because someone had taken the time to show me why I should do something in a certain manner, I was very happy to do it.
Hierarchy and innovation, not great mates
In their employee handbook Valve go on to say:
“But when you’re an entertainment company that’s spent the last decade going out of its way to recruit the most intelligent, innovative, talented people on Earth, telling them to sit at a desk and do what they’re told obliterates 99 percent of their value. We want innovators, and that means maintaining an environment where they’ll flourish.”
I’ll put my hand up right now and admit that Discovery is not an entertainment company, despite it sometimes being very entertaining to work here, yet I’ll completely agree with the sentiment of it being an absolute innovation killer to tell people exactly what they must and must not do. To me to provide the sort of environment that people are going to thrive in means everyone having a say and everyone moving forward.
Such a dynamic (yes my description and substitute whatever smanky term you want to use instead) way of doing things cannot, I believe, have a non-dynamic organisational backbone.
So let me try to put that on paper for you
I tried to draw a simple map of the relationships between a few of the employees in our company (disclaimer, I didn’t stop to think too long about who is linked to who very hard here, so if you’re on this chart and I didn’t link you correctly, sorry, it isn’t a real org chart because there wasn’t a whiteboard involved.)
when I tried to add just one more employee (Karsten) it just got far too messy:
My point is, that as a small company, we just don’t fit into the traditional hierarchical organisational structure. And to follow on from the point made by Valve, I don’t think it is in the best interests of our organisation or staff that we do.
Scientific interlude to counter excess HR fluffiness
Another digression (sorry) even evolution (Darwin’s tree of life) isn’t consider a tree these days, it has been recognised that due to the transfer of genetic information from and through viruses and bacteria there is an awful lot of our genome that doesn’t come from our direct ancestors, but from other species. It’s called horizontal gene transfer (HGT) and has been found to play a major role in forming species. To use this analogously, I should suggest that who you are working with, who influences you and who you influence are more important to who you are than the person that you supposedly report to.
Back to HR (or HCM, or whatever…)
Now I don’t think that either Discovery or Valve (or Dawin’s web(?) of life) are unique in this. I think the days of the hierarchy are numbered, and what is more, we are inventing and deploying the tools right now that will be its undoing.
Tooling up for the revolution
Enterprise social networking, whether using tools like Jam, Streamwork, Yammer, Google+ (we use this a LOT internally, it’s free, simple and powerful!) or even going more external with tools like Twitter, LinkedIn, and, so help you, Facebook is clearly in vogue. It should be a simple matter to leverage these tools (along with email ) to find out who is talking to who. From this we would have a clearer picture of who is talking to who, how often and in what formats. We could use this data to help us consult the right people. We already do this in many ways, but imagine having a system that could help us. In the same sort of way that GMail prompts you to include certain people in an email based on your past emails but that would also check the content of your message (I know this sound horrendous to some of you, but I’m just imagining stuff here, not planning for an actual solution, bear with me). The possibilities of how we could capture and utilise the connections between our employees to add value to the business are only just starting to be explored.
I’d push the analogy that I’m trying to make so far as to say that communities of interest are the new org units of enterprise. Although you might not send a leave request to be approved by your local ketchup appreciation group (I used to read the USENET alt.ketchup group at uni for a laugh, how the world has changed! I can’t even find a link to it now.) You are more likely to check that your vacation isn’t going to leave the project teams you are working with in the lurch, rather than checking with the team with whom you are theoretically assigned but haven’t worked with for the last 6 months.
When it comes to handling career goal planning, I think that we need to be encouraging everyone to be part of the process. (I happen to agree with Prof. Culbert about the usefulness of performance reviews, but strongly believe that goal setting is a great way to understand how to get to the next level, in a positive way.) 360 type reviews (where we reference and review with the people we are working with, rather than an arbitary “manager”) of the goals that we are setting allow ourselves allows us to help ourselves and our teams understand where are heading, without the soul-sucking negativity associated with most performance reviews. For such a distributed process, there is no benefit to a rigid structure where person A conducts the review for person B, C and D. Again I see great potential in the use of social communication tools to share and organise and optimise these processes.
Full circle
So back to my original musing, what does my organisation look like? I don’t think I know yet, but I think it’s going to be fluid. If I want to be part of a successful innovative company (and who doesn’t) I think it need to be able to change shape depending on how and why I’m looking. And my view of the organisation should be able to change that shape without me needing spend days of constant restructuring.
And to finally relate that to something SAP
Returning to my thoughts about the SuccessFactors Professional Edition product and its use of strict hierarchical structures. I don’t think that these do fit with how many SMB companies are choosing to operate today. Yet, I can see how a SaaS solution that is planning to integrate “social” into everything they do (one of the strong messages from SuccessConnect) will possibly get me there a lot quicker than an onPremise solution will. I hope that by posting this up people will read this and start to think about how we can start to leverage the tooling that SAP is providing to be more creative, dynamic and successful. SuccessFactors people, you have a real opportunity to create something in this space, please let’s build something awesome.
As per always, these are my own personal views, and do not necessarily represent those of the company I work for. I purposely take a line which is at times controversial and contrary to many people’s beliefs. I don’t think I’m correct, it’s just that no-one has convinced me otherwise yet. This blog was originally published at http://scn.sap.com/community/erp/hcm/blog/2012/07/09/my-organisation-looks-like but I thought it really ought to be here too. Partly inspired by Vijay’s blog about talent being unmanageable, and my thoughts on what does that mean about talent being managers. What I’d want to point out is that I see a future coming where out HRIS system may mean the end of people managers as we know then – thus solving the conundrum of how do we manage talent and/or should talent be managers.
