AMA: Knowledge Vortex Salesforce Functional Analyst, Bridget Hudacs on Technology Management

My experience with blending legacy systems and new technology is to use a middleware to integrate the two. With middleware integrations, there are a few best practices that I support: 1. Limited admins. Have you been in a system where every user is an admin? Seamless integrations are the big reason (especially if you receive pushback on limiting administrator access to tools) to limit who has access to adjust back end settings in a system. Well-meaning people can disrupt integrations by "just adding a field" or "updating the picklist values". (In full disclosure, have unintentionally disrupted systems by being given unnecessary admin access to them) 2. Document the integration. I'm a big fan of a data dictionary that identifies the system, field type, type of integration (single or bi-directional) etc. that is maintained as a living document among tech teams. I also live in the real world. So, within systems, update field descriptions to identify if they're used in integrations. Specifically identify the system and the direction of the sync in the description. From there, you can discuss with integration teams where the particular field maps to in other systems. And, in any tech debt reconciliation projects, you know which fields need special consideration. 3. Ensure that integration discussions are part of the discovery process for new projects. Does a project impact an existing integration? Does a new integration field/process need to be put together? Which system is the system of record? How does the integration support the solution proposed for the project? Project Managers or Business Analysts don't have to be highly technical to work with integrations, but should have a list of questions to ask when integrations are involved so the solution can support the user experience and data integrity.

I constantly look at the ROI and/or impacts of outcomes, and discuss those with the key stakeholders before moving forward with customization. What I have found is that people often present solutions without fully understanding the solution's impact on the rest of the tech stack/other users. When you discuss next steps in a positive way, you can get to the problem that they're trying to solve and find a better way to solve it. For example: "I got your request to do a real-time refresh of XYZ data. Because of the amount of data that we have, a real-time refresh would drastically slow down the system and make it difficult for your team to do their day-to-day work. Can you walk me through the challenges that you're having with the current data? I want to understand because I'm sure there's a way we can address those challenges and get you what you need." It's also key to make sure that your stakeholders know that you are their partner. You want to help them solve their challenges and make it easier for them to be successful in their jobs, and you demonstrate this on a regular basis.

In terms of business growth and the tech stack: 1. With customer growth, I want to ensure that the tools in the tech stack are robust enough for current and anticipated (2 - 3 years out) needs. I've been in situations where the company's use of a tool was too much for the tool to accommodate. You don't want systems erroring out because a tool you've chosen can't handle the workload that you provide. 2. With employee growth, I want to ensure that I have as few tools as possible to accomplish business objectives. The fewer tools in your tech stack, the easier it is to train and support end users. You have fewer integrations to manage and are able to troubleshoot issues faster. I've been in situations where I needed to support redundant tools, which could overwrite data from each other within the CRM system. So, how is this accomplished? 1. If possible, establish your team as the point of contact and contract negotiation for tech stack tools. If that's not possible, then champion a governance committee to approve new tools. Regardless of the method, you should have a clear, objective vetting process for new tools that is clearly communicated to end users. For example: * Do we already have a similar tool in the tech stack? * If so, is this a better tool for our current and anticipated needs? (looking at function, support and overall cost) Should we replace the existing tool with this one? * If not, is this the best tool to support our current and anticipated needs? * Does this tool meet IT security requirements? * Can this tool integrate with current core systems? 2. Talk to cross-functional colleagues about day-to-day requirements of their roles (ie are Business Development Representatives expected to cold call 50 numbers a day?) and strategic objectives for their departments. By understanding the needs of your end users, you can better vet tech tools. If possible, include key stakeholders in the vetting process to ensure the tools are robust enough for their functional needs. 3. When onboarding new technology, work with the new vendor and with key stakeholders to develop a written plan with timelines and responsibilities for the rollout. Onboarding system loads will often be vastly different (larger) than day-to-day loads. It's important to a) develop a plan that implements the new technology without impacting current systems; b) ensure end users are trained on the new tech, if necessary; and c) communicate the cut-over(s) to stakeholders (customers, staff) so they can manage the change as it relates to their day-to-day activities.

To foster a culture of continuous improvement, foster a culture of collaboration: 1. Encourage communication between team members and cross-functional teams. In the Kaizen philosophy, you can't improve a process if you're not doing it day-to-day. Listen, and give credibility to, the challenges of those who do the work. The "perfect" solution on paper may not actually work the best in practice. 2. Focus your team on finding ways to make processes 10% better, rather than finding a perfect solution. In Kaizen philosophy, it takes approximately 7 iterations of improving a process before it is optimally improved. Knowing that you don't have to solve everything at once can be freeing to find areas that can provide meaningful improvement: What is the biggest problem that the stakeholders have identified? How can that be improved? 3. Make sure stakeholders (those doing the work) are involved in the User Acceptance Testing (UAT) process. Their feedback is invaluable in ensuring that process improvements work for everyone, and can identify future improvements.

To negotiate relationships with technology vendors, the short answer is: come to the table prepared. 1. Know the (rough) amount of licenses that you're looking to acquire. You don't have as much negotiating power if you're looking for 1 or 2 licenses compared to 10+. 2. Know what you're looking for with a technology solution: What are your non-negotiables? What are you willing to negotiate or trade off on? 3. Understand what the competitors have to offer. Perhaps they have a capability that you're interested in, but don't need to have, and can use it to leverage a better deal. Also, don't be afraid to evaluate multiple vendors at the same time & let the vendors know that you're weighing multiple options. 4. Don't be afraid to ask for something that may seem "outside the box", like a free trial or additional services/support for free. You don't know if it's available unless you ask and the worst they can say is, "No." 5. Finally, know your technology vendor's business cycle. If you negotiate toward the end of a quarter or a fiscal year, you tend to get better prices. Once you've negotiated your pricing to get the best value, managing the relationship to get the best support is about you - or a member of your team - taking time to build a relationship with that vendor. If you have a dedicated rep or support team, have periodic touch bases where you ask questions or provide feedback on the product. Let them know what works well and what doesn't. Make sure that you have an agenda/purpose for the meetings so they don't become a waste of time, but that regular touchpoint is where you can be educated on new features that can assist with strategic goals, potentially join beta test groups to help the product become better and become better educated on the product that you've purchased. Ultimately, the better that you and your team understand your tech stack, the better you can avoid unnecessary redundancy and build a leaner, better supported RevOps system for your company.