C# · VB.NET / WinForms SQL Server · PostgreSQL · Microsoft Access Power Automate · SharePoint · Power BI ServiceNow · QAD / ERP · SFTP Barcode scanners & connected equipment
Disciplines
Manufacturing systems integration Data migration, parsing & transformation Workflow automation & operational reporting Process monitoring & shop-floor technology Legacy-system integration & process improvement
Selected project themes
Don't just read. Try it.
Interactive concept demos inspired by the types of problems I solve. All records, thresholds, and scenarios below are fictional.
01 / From request to resolution
Give every request a clear next step.
Approval work becomes difficult to track when decisions, purchasing, and receiving happen in separate conversations.
The approach
Use explicit states, configurable approval rules, and receiving checks. Keep incomplete requests open so a partial delivery doesn't disappear from view.
Workflow designPower AutomateSharePoint
My contribution
Redesigned and automated the purchase-requisition and receiving lifecycle using Power Automate and SharePoint, including status updates, exception reporting, reminders, packing-slip distribution, and warehouse handoffs.
Outcome
Eliminated manual reminder follow-up by warehouse clerks and supported timely receiving and payment workflows.
Try this
Change the request amount, advance through approvals, then record a partial or complete delivery.
REQUEST WORKBENCHFICTIONAL DEMO
Demo rules: every request needs manager approval; amounts above $5,000 also need finance approval. No real approvals or notifications are sent.
02 / Make exceptions visible
Spot drift before it crosses a safety limit.
My run-chart project monitors measurements against upper and lower safety specifications and sends alerts when readings trend toward either out-of-spec zone, supporting intervention before a limit is crossed.
The approach
Make both safety boundaries visible, monitor direction as well as individual readings, and distinguish an early trend warning from an actual specification breach. Give the team a clear signal to investigate and act.
Architected the monitoring system and integrated scanned work orders, network-connected scales, printed feedback, file transfer, SQL Server, Power BI, and Power Automate. Partnered with product engineering to establish thresholds and implemented early warnings and out-of-spec escalation through Teams and email.
Outcome
Replaced delayed, end-of-process detection with near-real-time visibility and immediate operator feedback, enabling earlier investigation and intervention.
Try this
Load an upward or downward trend, then add a measurement beyond either safety limit. Compare the early-warning alert with the out-of-spec alert.
MEASUREMENT MONITORSYNTHETIC READINGS
Samples
Within range
Out-of-spec samples
● MeasurementsGreen: central rangeAmber: near limitsRed: outside 48–52
Simulated notification log
Invented demo rules: safety limits 48–52 inclusive; early-warning bands 48–49 and 51–52. A warning requires 3 strictly rising or falling readings ending in the corresponding band. A breach takes priority. These are illustrative rules, not actual safety specifications or statistical control limits. Alerts are displayed here only; no messages are sent and no equipment is controlled.
03 / Catch issues before they travel
Make messy imports easier to resolve.
A small data issue can interrupt a much larger process when a file moves between operational systems.
The approach
Validate required fields, quantities, and duplicate identifiers before import. Explain the exact row-level issue so a user can correct it without guessing.
Data integrationSQL.NET concepts
My contribution
Applied transformation, validation, and data-quality checks as part of database migration and production-system integration work. This demonstration isolates those practices; it is not a separate claimed deployment.
Outcome
Supported data integrity during migration and integration. The row-level errors below are fictional examples of the validation approach.
Try this
Validate the sample batch, apply the example corrections, then validate again to unlock the simulated import.
IMPORT PREFLIGHT4 SAMPLE RECORDS
Row
Item
Quantity
Check
This browser-only simulation uses invented records. It doesn't connect to an ERP, database, or uploaded file.
04 / Modernize the data foundation
Reshape legacy data for a new schema.
My Access-to-PostgreSQL migration work included substantial parsing and transformation into newly named destination fields. This fictional example demonstrates how legacy values can become structured, usable SQL data.
The approach
Define the destination fields, parse combined source values, normalize formats, and map the results into the new schema. Preserve source identifiers and isolate parsing or conversion failures before loading, then reconcile the results.
Microsoft Access / MDBPostgreSQLParsing & transformationSchema mappingReconciliation
My contribution
Led the legacy Microsoft Access-to-PostgreSQL migration, including schema redesign, parsing and transformation, validation, and performance optimization.
Outcome
Established a redesigned database foundation for scalable reporting and laboratory-system use.
Try this
Try the parser to split a legacy string into newly named fields. Then run the sample batch migration, correct an invalid amount, and retry without duplicating loaded records.
MDB → POSTGRESQLFICTIONAL MIGRATION
Illustrative field mapping
Access field / type
SQL field / type
RecordID · AutoNumber
LegacyID · integer, unique key
LegacyText · Short Text
DepartmentCode + ItemCode + EntryDate
AmountText · Short Text
Amount · numeric(12,2)
IsActive · Yes/No
IsActive · boolean
Example format: department | item | YYYY/MM/DD. Edit the string to test parsing and validation.
New SQL field
Parsed value
DepartmentCode
—
ItemCode
—
EntryDate
—
Split values, trim whitespace, standardize codes, and validate the date before mapping.
Source rows5
Loaded rows0
Rejected rows0
Legacy ID
Source amount
Result
Browser-only concept demo; the parser and batch example run independently. Field names and parsing rules are invented, not an employer schema. No MDB file is opened and no SQL connection is made. Example correction uses a fictional verified value. A production migration would also require backups, relationship checks, application testing, and a cutover plan.
05 / Make ERP data useful beyond the ERP
Connect ERP structure to QA and scheduling.
My QAD-to-SQL BOM work brought product structure and routing into a SQL database, then translated that data for an ATS instance supporting QA checks and scheduling software. The import was updated to use SQL bulk loading in place of Excel interop.
The approach
Stage the exported data, validate parent/component relationships, and connect routing operations to the BOM. Preserve hierarchy so component quantities can be calculated across assembly levels, then translate the relevant structure and operation data for downstream QA and scheduling use.
QAD / ERP integrationSQL ServerVB.NETSQLBulkCopyBOM & routingATS integrationQA & scheduling
My contribution
Redesigned and optimized the SQL-based BOM and inventory upload workflow. The BOM project also connects product structure and routing data with downstream ATS QA and scheduling needs.
Outcome
Substantially shortened combined BOM and inventory upload processing. This was a shared workflow improvement, not a separate performance result for each demo.
Try this
Load the sample structure into the simulated reporting database. Change the build quantity to recalculate component demand, preview the translated QA and scheduling records, or introduce a missing routing operation to see the validation block.
Source structure · quantities per immediate parent
Parent
Component
Qty
Operation
DEMO-KIT
FRAME
1
10
DEMO-KIT
MODULE
2
20
MODULE
BRACKET
3
20
MODULE
FASTENER
4
20
Exploded BOM report · intermediate and leaf components
Level / item
Per kit
Required
Routing step
Illustrative downstream mapping
SQL-derived data
QA / scheduling use
Assembly & component structure
Expected component checklist
Routing operations
Ordered work steps
Build quantity
Planned assembly quantity
This preview illustrates the integration concept. The target fields, checklist behavior, and schedule shown here are invented; no ATS interface or company-specific QA rules are reproduced.
Re-created concept demo with invented items, operations, quantities, and reporting rules. No company exports, actual table definitions, source code, or QAD connection are included. This example omits scrap, effectivity dates, and unit conversions.
06 / Bridge vendor data and ERP imports
Turn inventory exports into manageable uploads.
My inventory program bridges equipment-vendor exports with a legacy QAD environment, parsing and reformatting records before splitting the output into batches compatible with the existing import process.
The approach
Translate the vendor's export structure into the fields needed by the receiving system. Keep records intact when splitting the output and make batch sizes clear so the upload process is manageable.
Developed the vendor-data parsing and upload-batching logic described here, as part of the broader BOM and inventory upload workflow that I redesigned and optimized.
Outcome
Prepared vendor records for the existing ERP import process and contributed to the combined reduction in BOM and inventory processing time.
Try this
Parse the fictional vendor export, review the mapped fields, and change the batch limit. An invalid quantity is held for correction; accepted rows are split without dropping or duplicating records.
Parsed destination fields · first 3 accepted records
CountRef
ItemCode
LocationCode
CountQty
Batch manifest · complete records, source order preserved
Batch
Records
First → last reference
Demonstration only. The vendor format, field names, validation rules, and small batch limits are invented. These are not actual QAD upload files or production size limits. No inventory records are sent or changed.
Behind the work
Technology with operations in mind.
I'm Gabrielle Thompson, a manufacturing IT professional with a master's degree in Information Technology Management and a bachelor's degree in Computer Science. I lead day-to-day manufacturing IT operations, manage budgets and capital projects, and supervise a direct report alongside hands-on software and data integration work.
My background combines shop-floor manufacturing experience with software engineering, laboratory-system integration, and technology leadership. I translate operational requirements into practical systems and support them through testing, deployment, training, and ongoing improvement.
01
Start with the process.
Understand the users, handoffs, and exceptions before designing the solution.
02
Make status visible.
Give people a clear view of what's happening, who owns it, and what comes next.
03
Design for exceptions.
Plan for incomplete information, partial completion, and recoverable failures.
04
Build for the handoff.
Pair implementation with clear documentation and practical support guidance.
Experience & contact
Explore the full picture.
Manufacturing IT leadership, capital-project delivery, software engineering, and process improvement.
These independently created concept simulations illustrate my approach to common operational challenges. They do not reproduce an employer's systems, source code, internal documents, production data, or approval policies. The contribution and outcome statements describe my experience; interactive records, thresholds, and results are fictional demonstrations.