Siemens

Siemens Global Business Services is the internal shared services arm of Siemens, handling process optimization, digital tooling, and operational infrastructure for the broader organization. The Toronto office sits within this global network, running projects that touch everything from low-code application development to enterprise analytics and AI adoption.

I joined as a process optimization intern reporting to my manager on the digital transformation team. The role was broad by design: GBS operates at the intersection of technology and operations, and the intern scope reflected that. In any given week I might be building a Mendix feature, redesigning a SharePoint page, debugging a Power BI dashboard, or fixing Python prompts for the team's generative AI tooling. The variety was the point. GBS needed someone who could move across tools and domains without needing a long ramp-up on each one.

What made this role distinctive was the organizational scale. Every tool I built or process I documented wasn't just for my immediate team. It was for a global network of GBS employees across multiple countries and time zones. The SharePoint I redesigned needed to make sense to someone in Munich as much as someone in Toronto. The dashboards needed to surface patterns that mattered to leadership in different regions. Working inside a company this size taught me that the hardest part of digital transformation isn't the technology. It's making sure the technology works for everyone who needs to use it.

The team's existing internal platform was scattered. Documentation lived in different places, project information was hard to find, and new hires had no structured entry point into how the team operated. My first major project was redesigning the team's SharePoint from the ground up, turning it into a single, navigable hub that the entire team could rely on.

I started by talking to the team. What information did people actually need on a daily basis? What did they waste time searching for? Where did new hires get stuck? The answers shaped the architecture. The redesigned SharePoint had dedicated sections for top projects with video walkthroughs and one-pagers, a team directory with profile pictures and roles, and a structured navigation that grouped related resources together instead of listing everything on a single page.

The project showcase section was particularly important. GBS runs dozens of initiatives simultaneously, and there was no centralized place to see what was in progress, what had shipped, or what the outcomes were. I worked with the team to identify the top five projects, created one-pager summaries for each, and built a layout that made the portfolio visible at a glance. Leadership could now point external stakeholders to a single page that demonstrated the team's impact.

The second layer of the SharePoint redesign was operational documentation. The team had recurring questions about how to do things: how to create a one-pager, how to onboard to Mendix, how to follow the correct process for specific workflows. These questions consumed time from senior team members who had to answer them repeatedly.

I created a dedicated SOP section with step-by-step guides for the most common processes. The idea was simple: when someone asks how to do something, you can link them to the guide instead of explaining it again. This freed up time for the team and created a living reference that could be updated as processes evolved. I also built an onboarding flow for new hires, a structured path through the SharePoint that introduced the team, the tools, and the workflows in a logical sequence rather than dropping someone into a sea of links.

Siemens GBS uses Mendix, a low-code development platform, to build internal applications that automate processes across the organization. I earned my Rapid Developer Certificate early in the term and then moved into active development work on the team's production applications.

The team maintained an Excel tracker of all Mendix widgets across their applications. Some were outdated, some had known issues, and some needed monthly updates. I inherited this tracker and worked through the backlog systematically: reviewing each outdated widget, determining whether it needed to be updated or replaced, and coordinating with the team on the changes.

Monthly widget maintenance sounds routine, but in practice it required understanding how each widget connected to the broader application logic. A widget update that broke a dependency could cascade into downstream issues. I learned to trace dependencies before making changes, a habit that would serve me in every technical role afterward. The work also involved suggesting improvements to the team, like proposing a headers system to improve navigation within the applications.

The most significant Mendix feature I worked on was an automated approval notification system. The team had an internal project approval workflow where, when a project reached a certain stage, designated process owners needed to be notified and given the ability to approve or request revisions. The existing process was manual: someone would check the status, find the right person, and send an email.

I designed and built the notification flow within Mendix. This included the internal project approval section with a pop-up interface, buttons for approve and revise actions that triggered notifications to the designated process owner, and classification level fields that determined the routing logic. I also researched Microsoft Graph Outlook integration as a potential path for sending notifications directly through the organization's email system rather than relying on in-app alerts alone.

The team needed visibility into how their projects and tools were performing. I built dashboards in Power BI that gave leadership a real-time view of project status, usage patterns, and operational metrics across the GBS organization.

The primary dashboard I built was for an internal initiative that needed a centralized view of its data. I started with the raw dataset, cleaned and manipulated it to surface the right metrics, and designed a multi-page dashboard with a homepage that gave a high-level overview before letting users drill into specific areas.

The design process went through multiple iterations. The first version surfaced the data but wasn't structured in a way that told a useful story. I revised the layout, adjusted the visualizations to highlight trends rather than raw numbers, and added interactive filters so leadership could slice the data by region, time period, and project type. The final dashboard became a reference point in team meetings. Instead of pulling numbers from different sources, the team could point to a single view.

Beyond the project dashboard, I worked on creating usage analytics for another internal initiative, tracking how internal tools were being adopted and where engagement dropped off. This required getting access to the dataset, meeting with the project lead to understand what metrics mattered, and building visualizations that surfaced actionable patterns rather than vanity metrics.

The analytics work taught me the difference between tracking everything and tracking the right things. Early versions of the dashboard included too many metrics. After feedback from the team, I stripped it down to the signals that actually drove decisions: active users, feature adoption rates, and time-to-completion for key workflows. Less data, presented clearly, was more valuable than comprehensive data that nobody had time to interpret.

Siemens was actively rolling out generative AI tools across the organization, and GBS was both a user and a builder of these capabilities. I worked on two fronts: improving the team's existing AI tooling and researching new integrations that could extend what was possible within the Mendix platform.

The team used an internal generative AI tool for various tasks, but the output quality was inconsistent. I was tasked with fixing the prompts that fed into it, revising the instructions so the model produced more reliable, structured outputs. This involved testing different prompting strategies, including methods like the Excel method for revising answers, and iterating on the prompt design until the outputs met the team's quality bar.

I also created a GenAI training agenda for the team, a structured timeline that walked people through how to use the AI tools effectively, what they were good at, where they fell short, and how to write prompts that got useful results. The goal was to move the team from sporadic AI usage to systematic adoption, where everyone understood when and how to use the tools in their daily workflow.

The more ambitious AI project was researching the Amazon Bedrock Connector for Mendix. The idea was to integrate large language model capabilities directly into the team's Mendix applications, enabling features like intelligent search, document summarization, and automated classification within the internal tools that GBS teams used every day.

I worked through the Mendix Academy courses on REST API design and publishing, studied the Amazon Bedrock connector documentation, and tested API patterns using Postman to understand how GET, POST, and PUT calls would need to be structured. The research laid the groundwork for a future integration. The technical feasibility was clear, and the architectural patterns were documented for the team to build on.

The work spanned platform design, application development, analytics, AI research, and operations, touching every layer of how GBS delivered digital transformation internally.

Siemens was the role where I learned what it means to build for an organization instead of a team. The tools were different every week, but the underlying challenge was always the same: figure out what people actually need, build it in a way that makes sense without you standing next to them, and document it well enough that it outlasts your time there.

Most of what I shipped wasn't technically complex. A SharePoint site, a dashboard, a notification flow, a set of SOPs. But the hard part was never the build. It was understanding the process well enough to know what to build, and making it clear enough that people across different offices and roles could use it without a walkthrough.

This was also the first time I worked with low-code and GenAI tooling in a production context. Both are powerful when the problem is well-defined and dangerous when it isn't. That lesson stuck with me.