Siemens

Siemens Global Business Services is Siemens's internal shared services arm, handling process optimization, digital tooling, and infrastructure for the broader organization. I joined the Toronto digital transformation team as a process optimization intern with a deliberately broad scope: Mendix development, SharePoint redesign, Power BI dashboards, and GenAI tooling, often in the same week.

What made the role distinctive was organizational scale. Work had to make sense to GBS employees across regions and time zones, not just my immediate team. The hardest part of digital transformation isn't the technology. It's building things that work without you standing next to everyone who uses them.

The team's internal platform was scattered. Docs lived in different places, project info was hard to find, and new hires had no clear entry point. I redesigned the team's SharePoint into a single hub the whole team could actually use.

I started by asking what people searched for every day and where new hires got stuck. That shaped the layout: top projects with walkthroughs and one-pagers, a team directory, and navigation that grouped related resources instead of dumping everything on one page.

GBS runs dozens of initiatives at once, and there was no single place to see what was in progress or what had shipped. I worked with the team to pull together the top five projects, wrote one-pagers for each, and built a portfolio view leadership could point external stakeholders to.

The second layer was operational documentation. The same questions kept coming up: how to write a one-pager, how to onboard to Mendix, how to run a workflow correctly. Senior people were answering them over and over.

I built an SOP section with step-by-step guides for the common ones, so you could link someone to a doc instead of explaining it again. I also put together an onboarding path for new hires: team context, tools, and workflows in order, not a wall of links.

GBS builds internal apps on Mendix. I got my Rapid Developer Certificate early in the term, then moved into active work on the team's production applications.

The team tracked every Mendix widget in an Excel sheet. Some were outdated, some had known issues, some needed monthly updates. I worked through the backlog: review each widget, decide whether to update or replace it, coordinate with the team on changes. A bad widget update could break downstream logic, so I learned to trace dependencies before touching anything. I also suggested a headers system to improve in-app navigation.

The biggest Mendix feature I shipped was an automated approval notification system. When a project hit a review stage, the right process owner had to approve or request revisions. Before that, someone checked status manually and sent an email. I built the flow in Mendix: approval pop-up, approve/revise actions, notifications to the right owner, and classification fields for routing. I also looked into Microsoft Graph Outlook integration so alerts could go through org email, not just in-app.

The team needed visibility into project and tool performance. I built Power BI dashboards for leadership: project status, usage patterns, and operational metrics across GBS.

The main dashboard was for an internal initiative that needed one view of its data. I cleaned the raw dataset, surfaced the right metrics, and built a multi-page layout with a homepage before the drill-downs. The first version showed the data but didn't tell a useful story. After a few iterations, I reworked the layout, highlighted trends over raw numbers, and added filters by region, time period, and project type. It became the reference in team meetings instead of pulling numbers from different places.

I also built usage analytics for another internal initiative: where adoption was strong, where it dropped off, and what actually mattered to the project lead. Early drafts had too many metrics. After feedback, I cut it down to what drove decisions: active users, feature adoption, and time-to-completion on key workflows.

Siemens was rolling out GenAI across the org, and GBS was both using it and building with it. I worked on two fronts: fixing the team's existing AI tooling and researching integrations that could extend Mendix.

The team had an internal generative AI tool, but output quality was inconsistent. I revised the prompts, tested different strategies (including the Excel method for answer revision), and iterated until outputs hit the bar the team needed. I also put together a GenAI training agenda: when the tools were useful, where they fell short, and how to write prompts that actually worked.

The bigger AI project was researching the Amazon Bedrock Connector for Mendix: LLM capabilities inside the apps GBS teams used every day (search, summarization, classification). I went through Mendix Academy on REST API design, read the Bedrock connector docs, and tested patterns in Postman. The research confirmed feasibility and documented the architecture for the team to build on.

The work touched platform design, app development, analytics, and AI research across how GBS ran digital transformation internally.

Siemens was where I learned what it means to build for an organization, not just a team. The tools changed every week, but the challenge was always the same: figure out what people need, build it so it works 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. The hard part was understanding the process well enough to know what to build, and making it clear enough that people across offices and roles could use it without a walkthrough. It was also my first time using low-code and GenAI in production. Both are powerful when the problem is well-defined and dangerous when it isn't.