Thursday, July 1, 2021

Consideration for Employee Hub Product

As a side project, I volunteered for defining the use cases for prospective/employee engagement portal few years ago. While HR Management system (e.g. PeopleSoft, workday, inhouse custom tools) provided variety of features but there were certain gaps related to employee engagement which employee hub product was expected to handle. Salesforce was intended as evaluation platform for building the product proposed for specific business unit. As I see, some of the use cases are still valid and up for grab.

Problem Statement

Track and monitor prospective "candidates" from interview shortlisting to offer acceptance

Engage actively with prospective "employees" from offer acceptance to onboarding phase

Address challenges/request from employees and provide a platform to collaborate on queries as cloud-based delivery rarely had team collocated.

Lack of engagement/communication touch points was causing disconnect at each level and high churn rate (declines/separation)

Business/Working Model

Prospective candidate list received from various channels were managed centrally on organization career portal and later exported into file and shared with respective talent units tagged to horizontal. Same file was used to manage the recruitment drives.

Manual process for assignment of candidates for interview process, capturing feedback on paper or online form/excel sheets

Connects with prospective candidates (PC), prospective/current employees (PE/E) primarily driven via the talent/human resource management team.

Solution Proposed

While it didn't reach till the solutioning stage but back of mind using process automation to track different stages of engagement was certainly there. Key considerations were-

  • Assignment rules to ensure there is no duplicate assignment of candidates with predefined forms/screen flows to capture feedback. 
  • Conversion from PC to PE on selection with further tracking in separate object to address communication challenges. 
  • Using activities to track list of items needed for onboarding process and to notify/email relevant units for smoother onboarding (like assets team for Laptop; security team for ID card, etc.). These regular connect and activity closure were expected to give an implicit indication on PE final conversion to E. 
  • Collaboration via chatter/private group to handle discussions related to projects and unit activities. 
  • Using email templates (for each communication type), auto assignments rules (for assignment of PC to interviewer or PE to a buddy), process builders, validation rules (to limit business rule violations), data loads (for capturing the candidate details), knowledge article for FAQs/documentation and so on. 

Cost of licenses, license type (community/platform/salesforce) and interaction between entities were not considered in initial stage.

L1 Use Cases

There were two broad level processes/use cases which product intended to cover - 

Employer key problem area - 

  • Candidates not turning up for interview (Outside the scope as handled by talent team but reverse engineering to revise the plans).
  • Prospective employees declining the offers.
  • Tracking accountability of interviewer for hiring only genuine candidate (principal-agent problem).
  • Last but not the least - driving engagement at project/unit level to address disconnects.

Employee (PE/E) key problem area - 

  • Lack of feedback or input from Employer on processing status of candidature for both selection/rejection scenario.
  • Disconnect and lack of communication from offer roll out till joining (this also led to deflection partially with trust as one of many other reasons).
  • Lack of touchpoints and navigation guidelines (while these are covered during induction but connect goes for toss).
  • Single platform for collaborating with point of contact for typical concerns faced by employees (e.g. continuous learning/certifications, policy links, project status, project documentation link, templates to be followed and so on).

Epilogue

While engagement was shelved after initial discussions and I too moved to another initiative, but got interesting insights while evaluating various use cases and capability mapping. 

Irrespective of tech choice (JS, Java, PHP or Salesforce) and associated cost it could have been an exciting product/idea to work on as it intended to cover some of the problem area industry wide. Some of the companies in 'best companies to work' list which I know indeed work on giving holistic candidate/employee experience and potentially the reason why they are in the list. Value based analysis (Anderson & Narus; Gyan Courtesy - Prof DVR Sheshadri) for any offerings is the key. :)

Saturday, June 19, 2021

Designing a simple approval app

Few year back had an opportunity to design M&A solution using Salesforce Lightning. Lightning was just introduced feature (Dec'15) and many of the so called base features of classic interface weren't available in lightning. After 5+ years there are few which are still in wish list. Mobile development wasn't mainstream and was not even considered in initial stage of plan. It was more of a strategic initiative ("cash strapped") to evaluate the system capabilities before putting more money or expanding. A high stake project considering user base involved for the life sciences/medical device organization. 

Problem Statement - 

  • Client's innovation unit was handling multiple opportunities throughout the year.
  • Each opportunities depending on their deal size (<1 Mn to >250Mn) had different approving units going up-to group CEO
  • All such approvals and reviews were happening over mails with no automated option for reminders or tracking mechanism to get real-time status of opportunity.
All this was leading to loss of potential acquisition opportunities to competitors. 

Business/Working Model - 
  • The overall model was classified into two broad area, typical of any acquisition process - Early Stage and Late Stage with sub-classification on Non Binding Term Sheets (NBTS) & Contracts deals.
  • Each deal type were further classified depending on funding source and associated units which had another sub-classification based on deal size range - <1 Mn, 1-10, 10-25, 25-50, 50-100, >100 Mn
  • The approval matrix and groups were different for each deal type/size and required either serialized approval or parallel approval model
Solution Proposed - 

A simple model to capture deals within the system with OOTB file attachment capability coupled with dynamic approval and custom reminder mechanism. Custom object based parameterization. No considerations on mobile as neither holy document called SoW specified it nor client wanted it. Anyways mobile development those days meant either customizing compact layouts for SF1 layout or going SDK route involving android/iOS developers to build Native, Hybrid or HTML apps depending on client ask. 

Fast forward 2021 - 

If I have to design solution in present time, I will probably think about mobile app first and then anything else. While lightning was introduced keeping mobile ready app in mind but as quite a few clients looked forward to have their own branded app salesforce revamped the mobile publisher few releases back.

Design would have certainly changed taking into consideration GA features now. I will probably go for metadata based parameterized solution. Will likely be using flows extensively for reminders instead of custom codes. incorporate state model, use feed driven approval as option and so on. And most importantly will probably evaluate mobile publisher capability to build the app which apparently give greater control and management of mobile app.

Fast forward future - 

And I am almost certain that even above solution will  look dull in another 3-5 years considering pace of technology evolution. May be system capability will get built to capture such opportunities automatically. Parameter based auto approval for low key items with random samples picked for evaluating the system decisions by stakeholders. 

P.S. - I was initially planning to write a note on mobile publisher capability and how easy it was for a not so techie guy like me to build an android app (prototype of course) but eventually got lost with the design and thought that how dull old solution looks once we have better technology available at our disposal. Last but not the least, detailed design was not given for obvious reason.