Hello there, I’mChisom Kanu

Business problem

Sales performance lived in monthly spreadsheets, so basic questions about which categories and regions were carrying revenue took hours to answer.

Solution

Cleaned and modelled the sales data, defined DAX measures for revenue, average order value and growth, and built a filterable dashboard by category, region, season and customer segment.

Insights

• A small group of categories generated the majority of revenue while occupying a disproportionately small share of inventory attention.
• Regional performance diverged sharply in peak season rather than across the year as a whole.
• Average order value, not order volume, explained most of the month-on-month revenue movement.

Recommendations

• Re-weight stock and promotion budget toward the categories driving revenue concentration.
• Plan regional campaigns around the peak window instead of spreading spend evenly.
• Track average order value as the primary sales KPI alongside total revenue.

Business problem

Admissions data was captured but never analysed, so staffing and bed planning ran on intuition rather than on observed demand.

Solution

Cleaned and standardised the admission records in Excel, then built a Power BI report with time-series admission volume, department load and length-of-stay breakdowns.

Insights

• Admissions clustered into predictable weekly peak windows rather than arriving evenly.
• A minority of departments absorbed a disproportionate share of total admissions.
• Length of stay varied far more by department than by patient demographic.

Recommendations

• Shift staffing rosters toward the identified peak admission windows.
• Review capacity in the highest-load departments before adding beds elsewhere.
• Monitor length of stay per department as an operational efficiency metric.

Business problem

A raw incident log gave no view of where risk actually concentrated, so mitigation effort had no ranking to work from.

Solution

Wrote MySQL queries to aggregate incidents by cause, state and operator, joining reference tables and filtering for the incidents responsible for material product loss.

Insights

• A handful of cause categories accounted for most of the total product lost.
• Incident counts and incident severity ranked states in very different orders.
• Repeat incidents clustered around a limited set of operators and corridors.

Recommendations

• Prioritise inspection budget by product lost rather than raw incident count.
• Target the top recurring cause categories with dedicated preventive maintenance.
• Track repeat-incident corridors on a standing risk register.

Business problem

The incident log held years of safety and cost data, but no one could answer basic operational questions from it — which year cost the most, which operators caused the most harm, or which product types were most dangerous.

Solution

Wrote MySQL queries using aggregations, grouped rankings, conditional filtering and joins to operator reference data, including handling columns with spaces and special characters via backticks.

Insights

• Total accident cost concentrated heavily in a single peak year rather than spreading evenly.
• One liquid type accounted for a disproportionate share of explosions.
• A small group of operators was responsible for most reported injuries.

Recommendations

• Prioritise inspection and audit resources against the top operators by injuries caused.
• Apply stricter handling controls to the liquid type with the highest explosion rate.
• Track property damage per operator as a standing safety KPI.

Business problem

MySQL Shell configuration guidance was scattered across reference docs, leaving DBAs without a practical, tested path from default install to tuned instance.

Solution

Researched, tested and wrote a sequenced six-part series with reproducible commands, benchmarks and recovery procedures, reviewed for technical accuracy before publication.

Insights

• Most default configurations left memory and CPU settings badly matched to the host.
• Disk I/O configuration produced larger gains than query rewriting in several tested scenarios.
• Backup and recovery steps were the most frequently skipped part of tuning guides.

Recommendations

• Follow the series as a sequenced playbook rather than as isolated tips.
• Benchmark before and after each configuration change.
• Validate recovery procedures on the same schedule as tuning work.