Efficiency and Empathy: A Conversation with MongoDB’s Director of Business Systems

Tech Ops at MongoDB is committed to implementing tools and improving processes that enable our teams to work more efficiently and effectively. Hear from Devika Saharya, Director of Business Systems, to learn more about how her teams are making an impact, her approach to leadership, experience as a member of the Asian American community, and the challenges and opportunities she’s taken hold of throughout her career.

This May, we’re also excited to announce the launch of our new employee resource group for employees who identify as Asian or Pacific Islander, MongoDB_API. Learn more about employee resource groups at MongoDB.

Jackie Denner: Hi, Devika. Thanks for sharing more about your team and experience with me today. Can you start by telling me a bit about business systems at MongoDB?

Devika Saharya: As the Director of Business Systems, I oversee two teams composed of Analysts and Engineers - the Enterprise Resource Planning (ERP) team and the Robotic Process Automation (RPA) team.

The ERP team is responsible for managing the various tools used across the company, such as Coupa, Concur, and NetSuite, which is our primary financial tool for closing our books.

Meanwhile, the RPA team constantly seeks to automate repetitive and mundane processes to help individuals and teams save time. They recently created an automated cycle of escalations and notifications for the yearly Docebo training, ensuring that employees stay compliant. This has saved our GRC team countless hours in checking and following up on noncompliant training.

Our teams maintain open communication with various stakeholders internally, such as Accounts Payable, Order to Cash, Revenue, General Ledger, Data Strategy, Sales Ops, and Governance Risk and Compliance, to name a few. By staying in touch with these stakeholders and keeping track of any upcoming changes, both the ERP and RPA teams have been able to make significant contributions.

This proactive approach to communication and collaboration has allowed our teams to anticipate and prepare for potential impacts on our systems, resulting in smoother processes and more effective outcomes.

JD: How are the ERP and RPA teams making an impact for MongoDB?

DS: Tech Ops mission is to be a collaborative and trusted partner, providing superior technology services to MongoDB and enabling our internal systems to be a source of competitive advantage. All of our work is directly aligned with this mission and supports MongoDB's broader business goals.

For example, the ERP team works closely with the Finance organization to ensure a smooth and efficient close, which is critical to the financial health of the company. They have successfully implemented several projects, including Cash Application and the Vendor Onboarding tool, Graphite, which have streamlined manual processes and improved overall productivity.

The RPA team, on the other hand, focuses on saving manual time and effort on business processes, which empowers users across the organization. They have delivered successful projects such as Dual Signature verification, PO Notifications, and MindTickle Automation, all of which have improved efficiency and accuracy.

Both the ERP and RPA teams are currently working on high-impact projects that will further enhance our company's performance and competitiveness.

Devika and her team

JD: What is your approach to leadership?

DS: I believe that change is the only constant, and my approach reflects a fine blend of transformational and servant leadership. My focus is on creating unity, developing bonds, creating energy, and instilling passion among my team members, with empathy serving as the foundation for all of this.

To promote open communication within the team, we have catch-up sessions every Friday where everyone has the opportunity to express their feelings and discuss any topics of interest. I also believe in sharing my own life lessons, skills, and training videos that can help my team members develop their own skills and stay tightly knit.

Recently, our RPA team started a 'know your team member' series, which has been a great success. This initiative has helped to further strengthen our bonds and improve collaboration within the team. Overall, my approach to leadership is centered on fostering a supportive and collaborative environment that encourages growth and empowers team members to achieve their full potential.

JD: May is Asian American and Pacific Islander Heritage Month. What has been your experience as a member of this community working in tech?

DS: I believe that everyone has their unique experiences when coming to the US, whether it's for work or study. In my case, I moved to the United States in 2012 after getting married. My initial years were challenging as I had to settle into a new country, start a new life, and build a brand new career. I faced numerous obstacles during this time, including failing multiple interviews, struggling with self-confidence, and experiencing discrimination that led to losing my first job.

Despite these challenges, I persevered and worked tirelessly to acquire new skills and knowledge. As a member of the Asian American community, I've gained a sense of confidence and discovered the potential of individuals while building a strong network. I consider myself blessed to have found a mentor within this community who also happened to be my first manager in New York City. He helped me overcome my insecurities, instilled confidence, and continues to guide me when I feel stuck.

One of the most valuable pieces of advice my mentor has given me is to weigh the pros and cons of every decision I make. I take every opportunity to meet him for coffee and discuss new concepts and ideas.

I would also like to emphasize the significant impact of mentorship and leadership programs offered at MongoDB. In particular, I've found MDB Women, our employee resource group for women employees, to be a constant source of support and learning opportunities.

JD: How have your identity and experiences made an impact on your career?

DS: What sets MongoDB apart is its rapid growth while still prioritizing its people. I have had the privilege of working with some of the best talent and have been presented with learning opportunities on a daily basis, making my experience both challenging and fulfilling.

A recent example of a challenge was rolling out a new Vendor Onboarding Tool. The process involved understanding how procurement and Accounts Payable onboard vendors, what paperwork is required, and how legal comes into the picture, providing valuable insight into different types of legal documents. It was an interesting challenge for both myself and the team, and we were able to successfully complete the project.

By joining the Tech Ops organization, there are multiple opportunities to overcome business challenges and make an impact on the future success of MongoDB.

Transform your career as an engineer or analyst on our Tech Ops team. View open roles on our careers site.

← Previous

Tag, You're It: Using MongoDB Labels to Drive DataDog Business Logic

MongoDB Atlas and DataDog work better together to enable you to take advantage of the automation, elasticity, and scalability of modern infrastructure and act on real-time information to make well-informed decisions. With the latest release of MongoDB’s DataDog integration, we’ve added the ability to send custom defined labels in Atlas, CM, and OM to tags on the DataDog metrics object. Applying tags to DataDog's metrics allows users to organize and categorize their metrics in various ways. Here's how the new DataDog metrics tagging works: Define key-value labels in MongoDB at the cluster level that get automatically sent to DataDog as metrics tags. You can define tags based on the attributes you want to track and then assign those tags to the relevant metrics. For example, a tag named "region" could be assigned to metrics representing servers in different geographic regions. Filter and group metrics in DataDog by tags. You can then use these tags to filter, group, and aggregate metrics in various ways. For example, you can group metrics by tags such as "application," "environment," or "owner" to gain insights into how different parts of your infrastructure are performing. You can also filter metrics by tags to view just the metrics you're interested in. Use tags to set alerts and dashboards. You can create alerts and dashboards in DataDog based on tags. This allows you to monitor specific aspects of your infrastructure, such as servers in a particular region or metrics related to a specific application. DataDog's metric tagging feature is highly flexible and customizable, allowing you to adapt it to your specific organizational needs. Effectively using metrics tagging will grant you a better understanding of your application’s performance and help organizations make data-driven decisions. Read on to see an example of how MongoDB’s DataDog tagging integration can help organize your metrics and how you can use it to drive your business’ monitoring requirements. Setting cluster labels in Atlas In the example below, I’ll use MongoDB’s Data API to access and configure my MongoDB Atlas data. In this case, I’ll use MongoDB’s Data API to set new labels on my MongoDB Atlas clusters. To explore the new MongoDB Data API, you can use the public Postman workspace provided by the MongoDB developer relations team. You can use the cluster configuration API endpoint to add labels to a cluster in MongoDB. You can then use the get all clusters endpoint to verify that your labels were applied correctly. Once you’ve labeled your MongoDB clusters, set up your DataDog integration as you would normally. For more information on configuring MongoDB’s DataDog integration, refer to the documentation here . Using DataDogs metrics tagging to drive business logic After setting up your DataDog integration, you’ll automatically start seeing the labels you previously defined in MongoDB show up as tags on your DataDog metrics. You can now use these tags to filter, organize, and define logic based on the needs of your business. As an example, you can filter results in the DataDog Metrics Explorer. If I only want to see metrics for clusters associated with the “leafy” application, I can use tags to filter the metrics I get back. You can also use tags to define custom logic for your DataDog monitors. In this example, I’m configuring monitors to trigger different priority alerts based on the metrics tags. When query targeting exceeds the threshold for production clusters, I’ll get a P2 alert. However, the same alert for non-production environments wouldn’t have the same priority. In this example, I can use the “usage” metrics tag to define different alerting priorities. And finally, Datadog metrics tagging can help you organize and filter data in dashboards. Metrics tagging enables you to easily group related data together and create more focused and specific dashboards. For example, you can use the app_name tag here to filter on just the leafy application. This will help you quickly identify and troubleshoot issues. Using tags effectively can grant deeper insights into your data and help your organization make more informed decisions to improve the performance and availability of your applications and infrastructure. This new enhancement to MongoDB’s DataDog integration provides significantly more flexibility in how you use DataDog and helps you get the most out of your investment. The DataDog integration is available on MongoDB Atlas on M10 cluster tiers and higher. Learn more about DataDog’s powerful tagging capabilities. If you’d like to see MongoDB’s DataDog integration in action, the easiest way to get started is to sign up for MongoDB Atlas , our cloud database service.

May 1, 2023
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024