Starting from around Minute 59, Paul says that it’s crucial to know the implementation differences between small-scale and large-scale customers. Can you tell me what it’s meant?
I know, that normally the following is true: The bigger the company, the greater the overhead/customization requirements. Therefore more planning outside the implementation itself is required and a larger amount of data, rules, workflows and connectors might be implemented.
Principles should be the same, am I right?
Deliver frequently
Be as standard as possible
Engage with Stakeholder before the implementation
Get the customer on board → Best case it’s enforced from the top down and the customer has designated resource owners
Prime connectors first etc.
Is there something more to consider? Also is there a real difference if the client migrates from an homegrown solution than if he does it from IIQ?
I am not sure that the presenter was trying to get at with large scale and small scale customers based on that clip. However, I think there are a couple of things to consider:
Large customers have more identities being created and managed. It is a best practice to have more standard procedures to facilitate the volume but there may be more requirements for customization as many companies grew through acquisition and have to accommodate different brand names in the email address, provisioning to different AD domains, and have many more types of workers (think how this might apply to different licensing requirements, more role definitions, etc.) Larger customers may also have more internal staff (or the ability to outsource) supporting identity at the conclusion of the project.
Smaller customers tend to have few identities being created and managed. They are more likely than a large customer that SailPoint is their first IGA. They tend to have fewer worker types and need may need fewer customizations. They also tend to have less internal staff to support identity.
If I were to just use these characteristics, I would think about it this way.
Large Customers
Focus on getting comprehensive requirements so that you can ensure that all use cases are covered
Look at how best to use ISC tools (rules, forms, workflows, etc.) to meet these requirements.
Make sure that the customer team is involved because they may be taking on a greater role with ISC after the implementation.
Small Customers
Focus on getting a standard set of requirements that will be easily to implement and maintain.
Make the processes as straight forward as possible. Have the customer change their practices to simplify the implementation.
Work with the customer to see how you/your company might be able to support them post go-live.
However, I think there is more variability than this with customers. I have had large customers who were getting their first automated IGA and were frustrated that everything could not be an exception. I have had small customers with mature practices and existing IGA tools and moving to SailPoint was just an upgrade. I have had large customers that don’t have staff to support IGA and small customers where there are multiple resources on every call. I have had companies of both sizes that are willing to say no to customizations and choose standard processes and I have had customers of both sizes where many exceptions must be handled. I have had customers of both sizes with differing expectations of what it will take to support ISC once its implemented.
It is more important to get to know your customer, their goals, their requirements, and their plans for the future. Ask questions about why did they choose SailPoint (was it for automation, certifications, and supportability)? What are their goals for the implementation? What are the requirements that they have for IGA? How flexible are they in trying to look at the problem from a different perspective? How will they maintain and support the system going forward? What is non-negotiable and must be done? What are their critical milestones and dates? From this, you generate a plan that will ensure your customer is successful. Following the best practices that you mentioned:
Deliver frequently - Find small units of work that are meaningful to the organization. Frequent smaller releases are often easier to implement that large complex integration sets.
Be as standard as possible - If the standard processes will work, use them. Look for opportunities to simplify. Add complexity only when absolutely necessary
Engage with Stakeholder before the implementation - Before and During the implementation - Make sure that you are on the right track throughout.
Get the customer on board → Best case it’s enforced from the top down and the customer has designated resource owners - It is always better if everyone is onboard with with project and it is supported top down.
Prime connectors first etc. - Make sure you are focused on the most important thing first - is it automation of new accounts? - then AD/Directory are probably critical first steps - is it certification? - then ERP may be important early on. Learn the customer’s key deadlines and plan accordingly.
I hope my thoughts gave you something to think about. I wish you the best on your certification.
